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ABSTRACT 


This  is  a  Decision  Support /Expert  System  design  proposal 
for  the  Naval  Aviation  Maintenance  Control  environment.  A 
survey  of  contemporary  literature  concerning  the  use, 
development  and  implementation  of  such  systems  is  conducted. 
A  general  examination  of  the  decision  maker's  problem  domain 
including  the  organization,  requirements  and  constraints  is 
presented.  Design  criteria  are  identified.  An 
adaptive/prototype  approach  to  design  and  system  development 
is  strongly  recommended.  Value  analysis  is  suggested  as  the 
method  for  justification  of  the  system.  Specific 
recommendations  for  future  development  and  implementation  of 
the  system  are  made. 
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I .  INTRODUCTION 


A.  BACKGROUND 

U.S.  Naval  Aviation  is  a  leader  in  employment  of 
sophisticated  technology  designed  to  reduce  pilot  workload  and 
increase  effectiveness  of  aircraft  such  as  the  F/A-18.  An 
example  of  such  technology  is  the  aircraft's  capability  to 
acquire  and  track  multiple  targets.  Use  of  this  type  of 
technology  is  partly  responsible  for  the  Navy's  continuing 
successful  performance  in  a  demanding  and  hostile  environment. 

Aircrew  mastery  of  this  technology  is  significantly 
aided  through  use  of  computers.  Besides  freeing  the  aviator 
from  tedious  details  in  system  operations,  computers  also 
provide  significant  decision  analysis  capability  in  target 
detection,  identification  and  engagement  procedures.  Properly 
configured  computers  make  it  possible  for  the  aviator  to 
concentrate  on  flying  the  aircraft  and  to  better  manage  the 
aircraft  under  various  scenarios. 

While  computer  technology  is  employed  in  aircraft  systems 
as  decision  aids  for  aircrew,  it  is  not  used  in  aviation 
squadrons  for  maintenance  managers.  Presently  there  is  no 
automated  decision  support  aid  available  for  those  who  manage 
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the  maintenance  on  increasingly  complex  aircraft  systems  at 
the  squadron  level.  The  Naval  Aviation  Logistics  Command 
Management  Information  System  (NALCOMIS)  represents  an  attempt 
by  the  Navy  to  establish  a  Management  Information  System  (MIS) 
which  captures  all  maintenance  action.  The  system  will 
undoubtedly  improve  maintenance  managers'  access  to 
information;  however,  the  manager  must  know  a  priori  what 
information  to  seek  and  how  to  employ  it.  A  Decision  Support 
System/Expert  System  (DSS/ES)  will  aid  the  manager  in 
considering  relevant  information  and  courses  of  action  for  a 
particular  problem. 

At  the  enlisted  level,  the  maintenance  manager  is  the 
Maintenance  Control  Chief  (MCC) .  The  MCC  is  generally  a 
no  nonsense  manager  and  leader,  who  has  proven  himself  "under 
fire"  in  stress  filled  operational  environments.  These 
individuals  become  experts  in  their  field  after  years  of 
dedicated  hands  on  experience.  During  this  process  they 
compile  vast  stores  of  heuristic  maintenance  knowledge,  and 
acquire  their  own  proven  individual  knowledge  bases. 

Inexperience  is  often  the  cause  of  needless  mistakes  which 
result  in  an  aircraft  launching  late  or  not  taking  off  at  all. 
Costs  are  thus  incurred  in  the  form  of  lowered  operating 
levels.  Computer  assisted  judgement  can  reduce  wasted 
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materials,  effort  and  time  and  result  in  better  decisions. 
Today's  squadrons,  faced  with  constrained  resources,  cannot 
afford  to  perform  at  less  than  peak,  efficiency. 

The  demanding  tempo  of  sea-going  squadrons  normally 
requires  around-the-clock  maintenance.  This  poses  a  serious 
problem--f inding  enough  qualified  experts,  MCCs,  to  direct  the 
maintenance  effort  24  hours  per  day.  The  problem  is  further 
exasperated  for  shore  based  squadrons  who  schedule  weekend 
maintenance  by  duty  section.  Additional  complications  for 
maintenance  control  occur  when  the  MCC  requires  emergency 
leave,  is  transferred  or  retires. 

McCaffrey  [Ref.  1]  proposed  that  the  maintenance  control 
environment  is  a  suitable  setting  for  implementing  a  DSS/ES 
to  aid  in  the  decision  making  process.  Specifically, 
McCaffrey  suggests  the  use  of  an  ES  to  schedule  the 
maintenance  workload  through  prioritization  of  required  jobs. 
A  DSS/ES  would  allow  the  development  of  a  decision  making 
heuristic  rule  base  for  solving  recurring  problems  in  an 
environment  plagued  by  high  personnel  turnover.  Although  its 
primary  purpose  is  to  help  the  less  experienced  manager,  a 
DSS/ES  designed  to  take  advantage  of  a  knowledge  base 
interface  may  also  help  a  seasoned  manager  maintain  focus  in 
a  stressful,  high  pressure  setting. 
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B.  OBJECTIVE  AND  RESEARCH  QUESTIONS 


The  objective  of  this  study  is: 

Specification  of  the  design  criteria  for  a  DSS/ES  in  the 
maintenance  control  environment. 

The  primary  research  question  in  this  study  is: 

What  are  appropriate  design  criteria  for  a  DSS/ES  in  the 
aviation  maintenance  control  environment? 

Subsidiary  research  questions  for  the  DSS/ES  are: 

1.  How  should  the  system  be  implemented? 

2 .  What  method  should  be  used  to  evaluate  the  system? 

3.  How  will  the  system  evolve? 


C .  METHODOLOGY 

McCaffrey  discussed  the  feasibility  of  using  an  ES  system 
in  the  maintenance  control  environment.  This  thesis  continues 
by  analyzing  the  DSS/ES  design  methodology  necessary  for 
successful  maintenance  control  implementation  through  study 
of  current  literature.  Conclusions  and  recommendations  about 
the  techniques  which  will  best  ensure  the  success  and 
acceptance  of  a  DSS/ES  in  maintenance  control  are  made. 

This  thesis  is  written  under  the  following  assumptions: 

1.  The  work  place  of  maintenance  managers,  maintenance 

control,  will  be  outfitted  with  computer  hardware. 
(This  will  be  the  result  of  NALCOMIS 

implementation . ) 

2.  Future  maintenance  managers  will  be  knowledgeable  of 
basic  computer  commands  and  operations. 
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3. 


Although  technology  will  change  with  time, 
maintenance  managers  will  still  confront  the  same 
types  of  problems  in  making  decisions  about  the  most 
efficient  and  effective  use  of  resources. 

D.  ORGANIZATION  OF  STUDY 

Chapter  II  is  a  discussion  of  the  more  popular  ideas  and 
theories  on  decision  making,  DSS/ES  design,  implementation, 
evaluation  and  evolution  of  such  systems.  Chapter  III 
describes  problems  faced  in  the  maintenance  control 
environment.  Chapter  IV  shows  how  DSS/ES  design  theory  can 
be  applied  to  maintenance  control.  Chapter  V  summarizes  the 
conclusions  and  recommendations.  The  Appendix  is  a  glossary 
of  acronyms  used  within  the  study. 
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II.  DSS/ES  THEORY ,  STRUCTURE,  DESIGN, 
EVALUATION  AND  EVOLUTION 


This  chapter  examines  a  broad  spectrum  of  literature  on 
prominent  thoughts  for  construction  and  implementation  of  a 
DSS/ES.  Its  purpose  is  to  identify  methodologies  and 
techniques  which  will  aid  in  designing  a  DSS/ES  for  use  in 
aviation  maintenance  control.  First  is  a  discussion  of  the 
human  decision  making  process  and  its  importance  to  system 
design.  Second,  DSS/ES  theory  is  analyzed  relative  to  the 
need  for  and  proper  application  of  such  systems.  Next,  the 
design  process  is  examined  with  focus  on  Representations, 
Operations,  Memory  Aids  and  Control  Mechanisms  (ROMC)  [Ref. 
2]  and  adaptive  design  methods.  The  chapter  concludes  with 
suggested  methods  for  successful  DSS/ES  implementation, 
evaluation  and  evolution. 

A.  DECISION  MAKING  THEORY 

It  is  important  to  analyze  the  process  humans  use  to  make 
decisions.  By  doing  so  we  are  better  prepared  to  design 
systems  which  emulate  the  process.  It  is  also  important  to 
study  the  decision  making  environment  of  the  organization. 
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Further,  consideration  must  be  given  to  an  individual's 
cognitive  style  and  how  that  affects  his  ability  to  assimilate 
and  use  data  in  the  decision  making  process.  These  issues  are 
examined  below. 

1 .  Tha  Decision  Making  Process 

The  decision  making  process,  according  to  Simon 
[Ref.  3],  involves  three  phases:  intelligence,  design  and 
choice.  See  Figure  2.1. 


Figure  2 . 1  The  Decision  Making  Process 

Intelligence  Phase — This  is  the  phase  in  which 
problems  are  identified  and  classified.  Raw  data  are  obtained 
from  the  environment  which  form  clues  to  identify  problems  in 
reaching  the  organization's  goals  or  objectives.  Once  a 
problem  is  identified  it  is  classified  into  a  definable 
category  by  the  decision  maker.  Categories  could  include,  for 
example,  programmed  versus  nonprogrammed  problems .  Programmed 
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problems  are  those  where  the  solution  is  in  the  form  of 
written  guidance.  The  decision  maker  must  conform  to 
procedures.  A  nonprogrammed  problem  exists  when  the  decision 
maker  has  complete  freedom  to  make  a  decision  without 
predefined  guidance.  The  Intelligence  Phase  ends  with  a 
problem  statement. 

D«cign  Pha •• — in  the  design  phase  alternative  courses 
of  action  are  conceived,  designed  and  analyzed  for 
feasibility.  This  involves  understanding  the  problem, 
generating  solutions  and  testing.  Also,  in  this  phase  a  model 
of  the  problem  situation  is  constructed,  tested  and  validated. 

Choice  Phase — -This  phase  involves  selecting  a 
particular  course  of  action  from  those  available.  A  choice 
is  made  and  implemented.  It  may  be  necessary  to  return  to 
the  intelligence  or  design  phases  if  better  problem  definition 
is  required  or  design  flaws  surface. 

The  design  of  a  DSS/ES  can  be  thought  of  as  invoking 
this  same  process.  The  input  and  selection  of  various  data 
for  analysis  might  be  referred  to  as  the  Intelligence  Phase, 
the  analysis  of  the  data  through  use  of  various  models,  the 
Design  Phase  and  selection  of  an  optimal  alternative  or 
solution,  the  Choice  Phase. 
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While  other  more  detailed  decision  models  exist,  such 
as  Soelberg' s  framework  for  analyzing  the  unprogrammed 
decision  process  [Ref.  4],  Simon  provides  a  simple,  functional 
model  for  use  in  DSS  design. 

2 .  Cognitive  Styles 

Research  in  the  area  of  cognitive  style  is  aimed  ac 
trying  to  understand  how  the  user  thinks.  How  does  he 
perceive,  collect  and  analyze  data?  If  users  can  be 
categorized  according  to  their  cognitive  styles,  then 
knowledge  engineers  can  design  friendlier,  more  effective 
systems . 

"The  feeling  has  been  that  if  more  is  known  about  the 
Various  types  of  cognitive  styles  and  if  the  users  of  a  system 
can  be  correctly  categorized  it  should  be  possible  to  design 
information  systems  that  are  more  frequently  used,  resulting 
in  greater  decision-making  effectiveness  and  are  better 
accepted  by  users."  [Ref.  5] 

Mann  cautions  of  investing  too  much  effort  in  research 
devoted  to  measuring  cognitive  styles  and  that  categorization 
of  an  individual's  cognitive  style  is  difficult.  Individuals 
may  also  change  their  style  over  time  or  when  presented  with 
different  data  to  analyze.  This  can  present  problems  if 
cognitive  style  analysis  is  necessary. 
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Mann  does  not  discount  the  value  of  further  cognitive 
research  but  does  surmise  that  present  systems  designed  to 
offer  the  user  a  variety  of  dialog  options  can  assist  users 
who  have  varying  cognitive  styles.  Huber  also  voices  a 
similar  opinion,  "...the  DSS  design  effort  should  be  directed 
toward  creating  a  DSS  that  is  flexible,  friendly  and  that 
provides  a  variety  of  options."  [Ref.  6]  In  many 
applications,  especially  those  with  a  variety  of  users,  system 
functionality  is  more  critical  to  success  than  tailoring  the 
system  to  a  particular  user's  style. 

3.  Organisational  Decision  Making 

The  decision  process  (intelligence,  design  and  choice) 
may  be  common  among  all  decision  makers;  however,  the  process 
can  be  greatly  influenced  by  the  environment  or  organization 
in  which  decisions  have  to  be  made.  According  to  Huber, 
"...organizational  environments  have  a  great  impact  on 
managerial  decision  processes  and  choices."  [Ref.  7] 

Management  science  literature  discusses  various  models 
of  organizational  decision  making.  Organizational  decisions 
are  decisions  which  do  not  relate  to  personal  purposes,  but 
to  organizational  purposes. 

Huber  analyzes  some  of  the  more  popular  organizational 
decision  making  models:  the  Rational  Model,  the 
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Political/Competitive  Model,  the  Garbage  Can  Model  and  the 
Program  Model.  [Ref.  7] 


The  Rational  Nodal  describes  an  environment  where 
available  information  is  used  logically  for  decision  making 
by  organizational  units  on  behalf  of  the  organization.  This 
model  is  often  used  by  organizations  in  self  description  to 
portray  a  desir  i  image  rather  than  reality. 

The  Political/Conpatitiva  Nodal  describes  a  decision 
making  environment  where  organizational  units  use  information 
in  decision  making  that  they  see  will  prove  favorable  to 
themselves.  It  can  easily  be  confused  with  the  Rational  Model 
by  decision  makers  as  they  attempt  to  justify  political 
decisions  as  rational  because  they  benefit  a  department  and 
therefore  the  company. 

The  Garbage  Can  Nodal  portrays  an  environment  where 
solutions  may  precede  problem  identification;  problems  may  be 
waiting  for  identification  and  ensuing  solution,  and  in  either 
case  an  opportunity  exists  for  the  decision  maker  if  he  takes 
action.  A  well  known  example  of  the  problem  being  preceded 
by  the  solution  is  the  3M  Company's  Post-it  Pads.  In  this 
case  the  solution,  a  nonpermanent  adhesive,  came  before 
identification  of  the  problem,  a  desire  to  attach  temporary 
notes  to  office  paperwork. 
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The  Program  Modal  emphasizes  the  effect  of  programs 
and  programming  on  organizational  decision  making.  This  model 
is  relevant  to  the  military  with  its  strong  dependence  on 
Standard  Operating  Procedures  (SOP) .  Certainly  any  decision 
making  system  which  involves  the  military  will  likely  find  its 
database  heavily  laden  with  written  rules  and  regulations. 

Huber's  central  point  is  that  organizational  decision 
environments  vary  greatly  and  have  considerable  impact  on  the 
decision  making  behavior  of  individuals.  For  this  reason 
DSS/ES  dialog  design  considerations  should  give  strong 
consideration  to  the  user's  decision  making  environment  as 
opposed  to  focusing  on  the  individual  user's  cognitive  style. 
[Ref.  6] 

4 .  Non-Computer  Aided  Decision  Support 

Any  decision  support  system  should  lend  structure  to 
the  decision  making  process.  All  decision  makers  acquire  or 
inherit  a  set  of  decision  making  tools  to  aid  with  the 
process.  Huber  has  made  a  distinction  between  a  computer 
aided  decision  support  system  as  a  ”DSS"  and  a  noncomputer 
aided  decision  support  system  such  as  file  cabinets,  index 
cards  and  reports,  etc.,  as  a  "dss". 

Very,  very  few  of  the  world's  managers  have  access  to 
a  Decision  Support  System  (a  DSS,  as  defined  by  the  books, 
articles  and  marketing  materials  that  use  this  term) .  On 
the  other  hand,  every  manager  has  a  ’’decision  support 
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system,”  (a  dss,  a  system  consisting  of  the  information 
sources  and  decision  aids  that  the  manager  draws  upon  as 
the  occasion  requires).  [Ref.  7] 

To  build  an  effective  DSS  a  design  engineer  must  have 
a  complete  understanding  of  the  user's  present  dss.  This 
insight  will  help  him  discern  the  information  tools  decision 
makers  rely  on.  These  tools  will  probably  be  present  in  some 
form  in  the  new  DSS. 

B.  DSS/ES  STRUCTURE  AMD  USE 

Articles  have  been  written  with  the  sole  purpose  of 
distinguishing  between  a  DSS  and  an  ES.  They  both  use 
computer  hardware  and  software  to  assist  decision  makers,  but 
each  has  unique  characteristics. 

The  following  describes  the  reasons  for  recent  interest 
in  the  development  of  such  systems  as  well  as  giving  attention 
to  the  definition  problem.  Additionally,  a  framework  used  to 
guide  knowledge  engineers  in  identifying  appropriate  DSS/ES 
problem  characteristics  and  in  comparison  of  DSS  and  ES  are 
provided. 

1 .  DSS  Theory 

Computer  systems  which  aid  decision  makers  are 
becoming  more  powerful  and  popular  with  improved  technology 
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and  user  awareness.  Reasons  for  the  current  interest  in  DSS 
are  attributable  to: 

1.  Improvements  in  hardware,  e.g.,  sophistication  of 
input/output  devices,  increased  speed,  portability, 
reduced  costs  and  increased  availability. 

2.  Development  of  user  friendly  programming  languages 
to  facilitate  system  developments. 

3.  Users  are  becoming  more  sophisticated  and 
knowledgeable  on  the  benefits  and  use  of  computers. 

4  .  A  DSS  fits  in  with  the  general  trend  in  information 
systems  development,  e.g.,  office  automation, 
professional  workstations,  distributed  computing, 
computer  graphics  and  advanced  integrated  systems 
(text,  voice,  graphics,  data) .  [Ref.  8] 

But  what  is  a  DSS?  How  does  it  differ  from  other 

information  systems  such  as  Electronic  Data  Processing  (EDP)? 

Are  the  boundaries  between  different  systems  clear?  The 

following  paragraphs  deal  with  each  of  these  problems. 

a .  Systems  Definition* 

According  to  Sprague,  "Decision  Support  Systems 
are  a  natural  evolutionary  advancement  of  information, 
technology."  [Ref.  9]  He  argues  that  there  are  clear  and 
definite  distinguishing  characteristics  between  EDP,  MIS  and 
DSS.  However,  Sprague  does  point  out  that  there  are 
differences  of  opinion  about  the  various  definitions.  Some 
claim  that  MIS  is  an  all  encompassing  term  for  information 
technology  as  a  whole  in  which  DSS  is  just  a  part. 
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Most  DSS  definitions  describe  systems  with  similar 
characteristics.  Sprague  and  Carlson  define  DSS  as, 
"...computer  based  systems  that  help  decision  makers  confront 
ill-stri.ctured  problems  through  direct  interaction  with  data 
and  analysis  models."  [Ref.  2] 

Recognizing  the  boundaries  which  separate  various 
systems  facilitates  their  identification.  Mason  [Ref.  10] 
contends  that  in  the  design  of  an  information  system  the 
"point  of  articulation"  or  separation  between  the  system  and 
the  decision  maker  will  define  the  system.  He  uses  five 
processes  to  characterize  a  system:  Source,  Data,  Predictions 
and  Inferences,  Values  and  Choice,  and  Action. 

The  Sourca  defines  the  physical  activities  and 
objects  relevant  to  the  business.  Data  refers  to  its 
observation,  measurement  and  recording  from  the  source. 
Infarancas  and  Pradictions  are  made  from  the  data.  The 
evaluation  of  inferences  with  regard  to  the  values  (objectives 
or  goals)  of  the  organization  and  choosing  a  course  of  action 
define  the  Valuaa  and  Choica  segment.  The  final  process  is 
taking  a  course  of  Action. 

If  the  "point  of  articulation"  lies  between  the 
Data  and  Pradictions  and  Infarancaa  segments,  inputs  to  the 
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system  are  in  the  form  of  "Requests"  and  outputs  are  delivered 


as  "Reports".  Mason  defines  this  type  of  system  as  a 
database.  See  Figure  2.2. 

If  the  separation  is  between  Predictions  end 
Inferences  and  Values  and  Choice,  with  inputs  as  "What  if" 
questions,  and  outputs  given  as  "If — then,"  then  the  system 
is  very  similar  to  what  we  think  of  as  a  DS3.  See  Figure  2.3. 


Requests 


Reports 

Information  Decision  Making  System 

System 


Figure  2.2  Database  System 


What  if?  Questions 


Information  Systems  Decision  Making  Sys 

Figure  2 . 3  DSS 
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Between  the  last  two  segments  Values  and  Choice, 
and  Action,  the  inputs  are  "Which  course  of  action  is  best?" 
and  the  output  is  a  "Recommendation."  This  describes  a  system 
most  would  identify  as  an  ES.  See  Figure  2.4. 


Which  course  of  action  is  best? 


ACTION 


Recommendat ion 


Information  System  Decision  Making  Sys 

Figure  2.4  ES 

Finally,  if  the  information  and  decision  making 
elements  are  combined  into  the  same  system  we  would  have  a 
Decision  Taking  System.  This  type  of  system  equates  to 
systems  such  as  the  air  conditioning  thermostat  in  homes.  It 
senses  the  environment  or  collects  data,  makes  an  inference 
and  a  choice  and  takes  action.  In  this  case  either  turning 
the  furnace  on  or  off.  At  no  point  does  the  user  of  the 
system  make  this  decision.  See  Figure  2.5. 
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Information  (and  Daciaion  Making)  System 
Figure  2 . 5  Daciaion  Taking  System 

b .  A  Framework 

An  organization  which  attempts  to  implement  a 
computerized  information  system  needs  to  determine 
specifically  which  type  of  decision  makers  it  is  meant  to 
support.  Managers  who  are  involved  in  the  daily  routine  of 
production  will  have  specific  and  current  data  needs  quite 
different  than  the  CEO  who  wishes  assistance  in  the  area  of 
long  range  strategic  planning.  For  these  reasons  a  guiding 
framework  is  needed  for  knowledge  engineers  to  design  more 
efficient  systems  targeted  for  the  users  they  were  developed 
to  serve. 

Gorry  and  Scott  Morton  [Ref.  11]  have  combined  the 
thoughts  of  Simon  [Ref.  3]  and  Anthony  [Ref.  12]  into  a 
framework  from  which  knowledge  engineers  can  more  efficiently 
target  systems  for  specific  decision  arenas  within  the 
organization . 
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Simon  classifies  decision  making  problems  as 
either  structured,  semi-structured  or  unstructured.  A 
structured  problem  is  one  in  which  all  three  phases  - 
intelligence,  design  and  choice  -  are  structured.  Here, 
decision  rules  are  used  routinely  for  recurring  problems.  A 
spreadsheet  would  be  an  example  of  a  solution  for  a  recurring 
and  structured  type  of  problem.  Semi-structured  problems  have 
one  or  two  decision  making  phases  unstructured.  Unstructured 
problems  have  no  structure  in  any  phase. 

Anthony  has  categorized  three  main  managerial 
levels  or  activities.  He  defines  them  as  Operational  Control, 
Management  Control  and  Strategic  Planning.  Operational 
Control  concerns  day-to-day  production,  ensuring  that  specific 
tasks  are  carried  out  effectively  and  efficiently.  Here,  data 
needs  to  be  timely,  accurate  and  detailed.  Managamant  Control 
is  an  activity  which  calls  for  decisions  regarding  the 
effective  and  efficient  use  of  resources  necessary  for 
attaining  an  organization's  goals.  Informational  needs  are 
a  mixture  of  those  required  for  operational  control  and 
strategic  planning.  For  example,  budget  preparation  requires 
that  consideration  be  given  to  plans  for  a  new  product  based 
on  monetary  assets  available  for  acquisistion .  Information 
is  often  acquired  through  interpersonal  interaction. 
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Strategic  Planning  is  the  process  in  which  management  sets  an 


organization's  goals  and  objectives.  Strategic  Planning 
problems  are  complex,  usually  nonrecurring  and  solutions  are 
often  framed  from  a  historical  perspective. 

From  these  ideas  the  framework  was  developed  as 
shown  in  Figure  2.6.  The  representative  actions  or  problems 
in  the  framework  are  ones  Gorry  and  Scott  Morton  believe 
typify  the  respective  management  activities.  Problems  below 
the  horizontal  dashed  line  are  candidates  for  DSS  aid.  MIS 
and  transaction  processing  systems  are  used  for  activities 
above  the  line. 

DSS  are  designed  for  aiding  semi-structured  and 
unstructured  problems.  Gorry  and  Scott  Morton  suggest  that 
by  developing  such  a  framework  for  organizations,  knowledge 
engineers  and  managers  can  identify  the  types  of  problems  for 
which  a  DSS  may  prove  beneficial. 

c.  Components  of  s  DSS 

Computer  based  DSS  are  built  around  three  main 
subsystems.  These  subsystems  are  the  Data  Subsystem,  the  Model 
Subsystem  and  the  Dialog  Subsystem  (Dialog-Data-Model) 
referred  to  as  the  DDM  paradigm.  [Ref.  2]  See  Figure  2.7. 
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Figure  2 . 6  Information  Systems  :  A  Framework: 


The  Dialog  Subsystem  is  that  portion  of  the  system 
through  which  the  user  interacts  with  the  entire  system.  Bui 
[Ref.  13]  claims  that  from  the  point  of  view  of  the  users, 
"The  DSS  is  the  interface."  He  also  states  that  although  a 
well  designed  user  interface  does  not  guarantee  the  success 
of  a  DSS,  "...its  judicious  design  will  definitely  encourage 
the  acceptance,  boost  the  usage  and  enhance  the  analytical 
effectiveness  of  the  DSS."'”’ 
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Figur4  2.7  Components  of  a  DSS 


The  Data  Subsystem  performs  all  data-related 
tasks,  i.e.,  it  maintains,  stores  and  retrieves  data.  Data 
retrieval  may  be  internal  or  even  external  to  the  system  such 
that  the  system's  database  is  tied  to  other  databases.  Data 
manipulation  is  controlled  through  use  of  a  database 
management  system  (DBMS) . 

The  Modal  Subsystem  is  the  third  major  component 
of  a  DSS.  It  analyzes  the  data  in  the  database  through 
"analytic  procedures  and  algorithms."  A  model  may  be  as 
simple  as  one  which  computes  the  interest  on  a  specified 
dollar  amount,  or  extremely  complicated  such  as  a  linear 
programming  model  with  many  variables.  The  importance  of  this 
subsystem  is  stated  by  Sprague  and  Carlson,  "It  is  the 


integration  of  models  into  the  information  system  that  moves 
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an  MIS  which  is  based  on  integrated  reporting  and  data 
base/data  communication  approaches  into  a  full  decision 
support  system."  [Ref*  2] 

2 .  Expert  Systems 

Expert  systems  are  designed  to  draw  conclusions  and 
make  decisions,  in  a  narrow  problem  domain,  just  as  an  actual 
human  expert  would.  In  fact,  where  the  DSS  is  a  system  which 
is  built  to  assist  the  decision  maker,  an  ES,  theoretically, 
may  supplant  the  need  for  the  full  time  presence  of  a  human 
expert . 

s.  Dmfxnxtxon/Charactmrxatxcm  of  ES 

Turban  defines  an  ES  as,  "...a  decision  making 
and/or  problem  solving  package  of  computer  hardware  and 
software  that  can  reach  a  level  of  performance  comparable  to 
or  even  exceeding  that  of  a  human  expert  in  some  specialized 
and  usually  narrow  problem  area."  [Ref.  14] 

Turban  cites  the  following  as  some  of  the  more 
general  and  commonly  accepted  characteristics  of  a  typical  ES : 

1.  Capture  and  preserve  perishable  expertise  from  one  or 
several  experts . 

2.  Apply  this  expertise  to  solve,  by  using  inferencing 
capabilities,  complex  problems  effectively  and 
efficiently . 

3.  Solve  problems  by  providing  answers  instead  of  data. 
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4.  Provide  an  explanation  of  how  solutions  are  derived. 
[Ref.  14] 

b.  Structure  of  mn  MS 

A  modified  framework  of  Turban  and  Watkins 
[Ref.  15]  used  to  describe  the  structure  of  a  ES  is  shown  in 
Figure  2.8. 


*************************************************** 


*************************************************** 
Figure  2.8  BS  Structure 

The  Knowledge  Base  is  to  the  ES  what  a  database 
is  to  a  DSS.  However,  the  Knowledge  Base  of  an  ES  is  unique 
in  that  it  contains  knowledge  as  well  as  facts.  Facts  are 
usually  raw  data  and  definitions.  Knowledge  is  usually  the 
heuristic  summation  of  the  expert.  Most  Knowledge  Bases  store 
heuristic  information  in  "Modus  Ponens"  form  — if /then  rules. 
Methods  of  acquiring  knowledge  or  heuristics  from  experts  is 
difficult  and  is  the  subject  of  an  entire  field  of  study.  In 
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fact,  knowledge  acquisition  is  often  referred  to  as  the 
"bottleneck"  in  ES  development.  [Ref.  16] 

The  Infaranca  Engine  is  the  brain  of  the  ES.  It 
is  basically  a  computer  program  which  uses  various  methods 
for  searching  through  the  rule  base  to  derive  a  conclusion. 
Common  operations  employed  for  conducting  searches  through 
the  rule  base  are  either  forward  or  backward  chaining  using 
either  a  depth  or  breadth  type  of  scan. 

The  Blackboard  or  work  place,  is  the  working 
memory.  Here  facts  are  entered  and  stored  which  pertain  to 
the  specific  problem  at  hand.  The  Blackboard  also  records  and 
displays  for  the  user  if  desired,  the  intermediate  results  of 
the  system  on  its  way  to  a  final  conclusion. 

The  Uaar  Intarfaca  is  that  portion  of  the  system 
which  relates  to  the  Dialog  component  of  a  DDM  paradigm.  It 
is  through  the  user  interface  that  the  machine  and  user 
exchange  queries  and  responses  to  solve  problems.  A  natural 
language  interface  may  be  used. 

The  Juatifiar  allows  the  user  to  see  why  the 
computer  formed  the  conclusion  it  did.  It  allows  the  user  to 
determine  "how"  a  conclusion  was  reached  and  "why"  a 
particular  alternative  was  rejected. 
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3.  Comparison  of  DSS/ES 


Both  a  DSS  and  an  ES  are  designed  to  aid  users  in  a 
decision  making  environment.  There  are  many  similarities  and 
differences  between  the  two  systems. 

The  objective  of  a  DSS  is  to  support  the  user  in  the 
decision  making  process  by  providing  access  to  data  and 
models.  The  objective  of  an  ES  is  to  provide  the  user 
with  a  conclusion  or  decision  significantly  better,  or 
more  often  correct,  than  the  user  could  reach.  A  DSS 
allows  the  user  to  confront  a  problem  in  a  flexible, 
personal  way  in  manipulating  the  data  and  models.  With  an 
ES,  the  user  has  little  or  no  flexibility.  [Ref.  17] 

Table  2.1  [Ref.  15]  summarizes  some  of  the  more 
general  differences  between  a  DSS  and  an  ES . 


C.  DESIGN  METHODS 

The  design  of  decision  support  systems  and  expert  systems 
has  been  described  as  more  art  than  a  science.  Each  field  has 
evolved  its  own  design  methodologies.  In  addition,  these 
techniques  differ  from  established  information  systems  design 
procedures.  A  combination  of  accepted  DSS  and  ES  design 
techniques  may  prove  to  be  a  prudent  strategy  for  building  a 
system  and  is  examined  in  this  thesis. 

DSS/ES  development  is  often  difficult  to  justify  in  terms 
of  dollars  saved  or  return  on  investment.  Alternatives  to 
cost-benefit  analysis  are  frequently  required  because  of 
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TABLE  2 . 1  THE  DIFFERENCES  BETWEEN  DSS  AND  ES 


DSS 

ES 

Objective 

Assist  human 

Replicate  expert 
and  replace  him 

Who  makes  decision 

The  human 

The  system 

Major  orientation 

Decision  making 

Xfer  of  expertise 
( human -mch-human ) 

Query  direction 

Human  queries 
the  machine 

Machine  queries 
the  human 

Clients 

Individual  and/or 
group  users 

Individual  user 

Manipulation 

Numerical 

Symbolic 

Problem  area 

Complex,  wide 

Narrow  domain 

Database 

Factual  knowledge 

Procedural  and 
factual  knowledge 

unique  characteristics  of  decision  support  and  expert  systems 
as  compared  with  transaction  processing  systems.  Also, 
because  DSS/ES  functions  and  outputs  are  not  specific  and 
easily  defined  as  compared  to  systems  such  as  transaction 
processing  systems,  its  evolutionary  life  cycle  tends  to 
differ.  In  the  following  paragraphs  these  issues  and  others 
are  addressed  and  options  are  proposed  to  contend  with  the 
atypical  attributes  of  DSS/ES. 
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1 .  DSS/XS  Design 

The  popular  system  life  cycle  model  consists  of  five 
stages.  These  are  design,  construction,  implementation, 
operation  and  maintenance.  Slight  variations  exist  but  in 
general  it  is  around  this  framework  that  traditional  systems 
analysis  and  design  methods  are  based.  The  systems  life  cycle 
approach  has  proven  to  be  suitable  for  designing  structured 
systems  capable  of  performing  repetitive  tasks. 

This  is  not  the  best  method  for  designing  a  DSS.  Most 
authors  agree  that,  "The  way  of  designing  a  DSS  is  different 
from  that  of  a  transaction  processing  system,"  [Ref.  18]  and 
that,  "DSS  has  peculiarities  that  make  it  unique  among  the 
rest  of  MIS."  [Ref.  19]  "A  fundamental  assumption  in  the 
traditional  "life  cycle"  approach  is  that  the  requirements  can 
be  determined  prior  to  the  start  of  the  design  and  development 
process."  [Ref.  18]  This  assumption  does  not  always  hold  true 
when  building  a  DSS.  Alternative  methods;  Representations, 
Operations,  Memory  aids  and  Control  mechanisms  (ROMC)  and 
adaptive  design,  provide  the  design  techniques  more  suited  for 
a  DSS. 
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m.  Thm  ROMC  Dmmign  Mmthod 


Sprague  and  Carlson  propose  ROMC  as  a  framework 
for  defining  the  functional  requirements  and  capabilities  of 
a  DSS . 


The  approach  is  based  on  a  set  of  four  user-oriented 
entities:  Representations,  Operations,  Memory  Aids  and 
Control  Mechanisms.  The  capabilities  of  the  DSS  from  the 
user's  point  of  view  derive  from  its  ability  to  provide 
representations  to  help  conceptualize  and  communicate  the 
problem  or  decision  situation,  operations  to  analyze  and 
manipulate  those  representations,  memory  aids  to  assist 
the  user  in  linking  the  representations  and  operations 
and  control  mechanisms  to  handle  and  use  the  entire 
system.  [Ref.  2] 

Representations  facilitate  the  user' s  portrayal 
of  his  problem  and  the  objects  associated  with  the  problem. 
A  Taxi  Cab  company  in  a  large  city  would  have  a  map  of  the 
city  with  the  location  of  its  taxis.  This  is  used  to  help  the 
dispatcher  picture  where  the  cabs  are  at  any  given  moment. 
A  computer  screen  can  show  this  in  much  the  same  way  allowing 
the  user  to  visualize  the  situation.  For  example,  the  display 
on  the  screen  could  show  green  dots  representing  empty  cabs 
and  red  dots  representing  cabs  with  fares.  See  Figure  2.9  #1 
for  more  examples. 

The  Operations  portion  of  the  ROMC  technique 
relies  heavily  on  Simon's  intelligence,  design  and  choice 
scheme.  The  system  must  have  the  capability  to  gather  and 
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manipulate  data  from  various  sources  to  give  the  user 
meaningful  output.  See  Figure  2.9  #2. 

Memory  aids  afford  the  user  a  convenient  means  to 
record  intermediate  data  inputs  as  well  as  long  term 
information.  For  example,  a  catering  service  receives  orders 
and  must  keep  a  record  of  a  customer's  requests  for  an  event. 
The  person  taking  the  order  writes  it  down  on  a  receipt  or  a 
note  pad.  A  computer  scratchpad  does  the  same  job.  Given 
proper  backup  habits,  it  can  not  get  lost  or  misplaced  as 
easily  as  the  order  forms.  It  also  provides  an  easy  means  to 
check  customer  data  for  details  such  as  payment  habits.  See 
Figure  2.9  #3. 

The  Control  Mechanisms  give  the  user  the  power  to 
manipulate  the  representations.  Included  are  help  commands, 
menus  and  access  to  command  languages  for  experienced  users 
desiring  more  power.  Control  Mechanisms  may  be  the  most 
important  of  the  four  in  the  long  run.  "The  control  aids  may 
be  crucial  to  the  success  of  the  DSS  because  they  help  the 
decision  maker  direct  the  use  of  the  DSS  and  because  they  must 
help  the  decision  maker  acquire  the  new  styles,  skill  and 
knowledge  needed  to  make  effective  use  of  the  DSS."  [Ref.  2] 
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DECISION  MAKERS’  USE 


DSS  PROVIDES 


1.  Conceptualizations 

•  A  cily  map 

•  Relationship  between  assets 
and  liabilities 


2.  Different  Decision-Making  Proc¬ 
esses  and  Decision  Types.  All 
Involving  Activities  tor  Intelli¬ 
gence.  Design,  and  Choice 

•  Gather  data  on  customers 

•  Create  alternative  customer 
assignments  for  sales  person¬ 
nel 

•  Compare  alternatives 

3.  A  Variety  of  Memory  Aids 

•  List  of  customers 

•  Summary  sheets  on  customers 

•  table  showing  sales  personnel  and 
their  customer  assignments 

•  File  drawer  with  old  tables 

•  Sciatch  paper 

•  Staff  reminders 

4.  A  Variety  of  Styles.  Skills,  and 
Knowledge  Applied  Via  Direct, 
Personal  Control 

•  Accepted  conventions  tor 
interpersonal  communication 

•  Orders  to  staff 

•  Standard  operating  procedures 

•  Revise  orders  or  procedures 


1.  Representations 

•  A  map  outline 

•  A  scatterplot  of  assets  vs.  liabil¬ 
ities 

•  A  graph  of  monthly  asset/ 
liabilily  ratios 

2.  Operations  tor  Intelligence, 

Design,  and  Choice 

•  Query  the  data  base 

•  Update  list  to  show  assign¬ 
ments 

•  Print  summary  statistics  on 
each  alternative 

3.  Automated  Memory  Aids 

•  Extracted  data  on  customers 

•  Views  of  customer  data 

•  Workspace  for  developing  assign¬ 
ment  tables 

•  Library  for  saving  tables 

•  Temporary  storage 

•  DSS  messages 

4.  Aids  to  Direct,  Personal  Control 

•  Conventions  for  user-computer 
communication 

•  Training  and  explanation  in  how 
to  give  orders  to  the  DSS 

•  Procedures  formed  from  DSS 
operations 

•  Override  DSS  defaults  or  pro¬ 
cedures 


Figure  2.9  ROMC  Deeign  Method  [Ref.  2] 
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In  other  words  the  control  mechanisms  must  be  strong  enough 
to  help  the  new  user  in  becoming  comfortable.  They  must  also 
be  flexible  and  yield  power  to  the  experienced  user.  Users 
will  demand  more  out  of  the  DSS  as  they  become  familiar  with 
its  capabilities.  See  Figure  2.9  #4. 

It  should  be  noted  that  the  ROMC  method  is  not  the 
actual  design  methodology.  "The  ROMC  approach  is  a  tool  for 
focusing  the  systems  analysis  (of  the  decision-making  system) 
preceding  the  design  of  the  DSS  and  for  structuring  the  actual 
DSS  design. "  [Ref.  2]  In  effect,  the  ROMC  approach  "packages" 
the  dss  into  a  DSS. 

Jb .  Adaptive  Dmmign 

ROMC  enables  the  systems  analyst  to  identify 
necessary  attributes  of  a  DSS.  However,  it  is  difficult  to 
recognize  all  of  the  features  the  system  should  have  from  the 
onset  of  a  project  nor  is  the  complete  problem  domain  always 
recognized . 

The  adaptive  design  approach  allows  for  the  DSS 
to  evolve  as  more  becomes  known  about  the  problem  area.  It 
is  well  suited  to  DSS  because  as  Hogue  and  Watson  state, 
"...  a  DSS  is  never  completely  finished."  [Ref.  20]  One 

reason  that  a  DSS  is  never  finished  is  "...because  the 
decision  maker  or  user  cannot  define  the  functional 
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requirements  of  the  DSS  in  advance."  [Ref.  9]  "Also,  as  an 
inherent  part  of  the  DSS  design  and  implementation  process, 
the  user  and  designer  will  'learn'  about  the  decision  task  and 
environment,  thereby  identifying  new  and  unanticipated 
functional  requirements."  [Ref.  18]  By  assuming  an  adaptive 
attitude  designers  and  users  readily  accept  necessary  changes 
and  improvements  resulting  in  a  more  effective  system. 

Use  of  an  adaptive  strategy  has  not  solved  all 
complications  encountered  in  building  a  DSS.  When  a  system 
is  nearing  completion  and  it  is  discovered  that  a  remaining 
essential  function  is  either  too  difficult  or  expensive,  the 
entire  project  may  be  jeopardized.  The  options  at  this 
juncture  range  from  inconvenient  to  disastrous  as  decisions 
must  be  made  regarding  the  future  of  the  project, 
c.  The  Archipelagian  Approach 

Bui  and  Sivasankaran  propose  a  solution  to  this 
problem  in  the  form  of  an  Archipelagian  Approach  to  DSS 
design.  This  approach  makes  extensive  use  of  adaptive  design 
techniques  except  in  regions  with  high  structure.  In  the 
structured  domain  the  authors  advocate  less  user  involvement 
and  lean  toward  traditional  design  methods. 

The  archipelagian  approach  is  a  means  to  identify 
and  deal  with  obstacles  before  the  project  is  started.  "The 
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method  works  by  (i)  dividing  complex  ill-structured  problems 
into  'islands'  of  both  ill-structured  and  structured  sub¬ 
problems,  (ii)  identifying  and  determining  the  adequacy  of 
tools  for  their  implementation,  (iii)  alerting  the 
developer's  attention  to  possible  infeasible  aspects  of  the 
system  early  and  (ivj  suggesting  an  implementation  scheme 
that  'bridges'  these  islands  in  a  manner  that  (the) 
development  sequence  best  satisfies  the  user's  priorities  and 
system  builder's  requirements.”  [Ref.  21] 

Accomplishability  and  Imperative  Factors  are 
assigned  to  the  various  models  and  then  combined  in  a  formula 
to  reach  a  Development  Priority  Factor  (DPF) .  The  DPF  is 
used  to  determine  which  modules  should  be  built  first.  Use 
of  this  method  will  result  in  building  the  hardest  and  most 
critical  parts  of  the  system  first.  It  will  in  turn  ensure 
that  a  large  outlay  of  funds  does  not  lead  to  an  infeasible, 
yet  almost  complete  project. 

d.  Syatmm/Snvironmant  Definition 

Before  design  begins  it  is  important  to 
distinguish  a  system's  boundary  to  facilitate  design 
engineers'  ability  to  identify  the  inputs  and  outputs.  Efraim 
Turban  describes  a  system  in  terms  of  inputs,  processes  and 
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outputs  as  well  as  defining  the  clear  separation  between  the 
system  and  its  environment.  Figure  2.10  [Ref.  14] 

Turban' s  system  characterization  lends  itself  well 
to  a  manufacturing  scenario  where  the  raw  materials  are  input 
into  the  system  and  processed  through  various  activities  to 
provide  the  desired  output.  The  success  of  the  output, 
measured  by  quantity,  quality,  performance,  etc.,  is 
determined  by  the  decision  maker.  This  constitutes  "searching 
the  environment"  for  possible  problems,  (the  first  step  in  the 
decision  making  process,  intelligence) .  This  evaluation  of 
the  output  calls  for  modification  of  elements  within  the  input 
or  the  process. 

There  are  also  external  fators  which  have  an 
effect  on  decision  making  called  environment  elements.  These 
include  weather,  customers,  vendors  and  competition,  elements 
existing  outside  the  system's  boundry.  To  be  termed  an 
environment  element  Turban  claims  two  tests  must  be  passed. 
First,  the  decision  maker  should  be  unable  to  manipulate  the 
element.  Second,  the  element  must  have  an  affect  on  system 
goals . 

With  the  environment  and  the  factors  affecting 
system  output  identified  the  designer  gains  a  clear  and  basic 
representation  of  the  system  he  is  trying  to  construct. 
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Customer* 


Government 


Banks 


Vendors 


Heather  Competition  Prices  Costs 
Figure  2.10  The  System  and  Its  Environment 

e.  Other  Design  Conm±dmr*tionm 

Other  design  considerations  include  incorporating 
existing  hardware  and  software  when  possible  and  structuring 
the  DSS/ES  such  that  the  user's  abilities  may  range  from 
computer  novice  to  expert. 

The  database  component  provides  the  greatest 
opportunity  to  use  existing  assets.  Having  a  database  prior 
to  building  a  DSS  will  reduce  development  expense  and  data 
redundancy  and  will  simplify  design.  [Ref.  2]  An  impediment 
to  using  an  existing  database  is  compatibility  with  the 


hardware  and  software  selected  to  support  the  DSS/ES.  This 
must  be  considered  prior  to  making  design  decisions. 

D.  EVALUATION  AND  EVOLUTION 

The  need  to  discern  certain  design  criteria  ranging  from 
an  understanding  of  decision  making  factors  to  definition  of 
the  problem  environment  has  been  identified.  ROMC  and 
adaptive  design  have  been  proposed  as  construction  methods, 
however,  before  any  system  can  be  built  there  must  be  some 
justification  for  the  expense  that  will  be  incurred.  This  can 
be  difficult  when  a  complete  description  of  the  system's  final 
capabilities  is  not  known.  Should  a  cost-benefit  analysis, 
utilizing  best  guess  information,  or  some  other  technique 
capable  of  accommodating  the  unknowns  be  used?  What 
accommodations  in  design  must  be  considered  to  facilitate 
system  evolution  demanded  by  changing  technology  and  user 
requirements?  The  answer  lies  in  the  use  of  both  value 
analysis  and  adaptive  design. 

1.  Evaluation:  Valua  Analysis 

"Traditional  cost-benefit  analysis  can  be  performed 
successfully  for  DSS  that  display  a  high  degree  of  structure, 
aim  at  decisions  that  are  made  in  a  fairly  certain  environment 
and  primarily  address  the  intelligence  phase."  [Ref.  19]  As 
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intangible  benefits  come  into  play  cost-benefit  analysis 
becomes  more  complex. 

The  managers  (users  of  DSS)  perceive  the  main 
intangible  benefits  to  be:  facilitation  of  thoughts, 
improvement  of  communication  and  a  sense  of  success  and 
capability  to  perform  sensitivity  analysis.  Evaluation 
of  intangible  benefits  is  subjective,  sometimes  impossible 
and  as  the  weight  of  such  benefits  increases  in  the 
valuation  process,  so  does  the  potential  gap  between  the 
value  and  price  of  the  system.  [Ref.  19] 

Many  authors  agree  with  Keen  that: 

Traditional  cost-benefit  analysis  is  not  well-suited 
to  DSS.  The  decision  to  build  a  DSS  seems  to  be  based  on 
value,  rather  than  cost.  The  system  represents  an 
investment  for  future  effectiveness.  A  useful  analogue 
is  management  education.  A  company  will  sponsor  a  five 
day  course  on  strategic  planning,  organizational 
development  or  management  control  systems  on  the  basis  of 
perceived  need  or  long  term  value.  There  is  no  attempt 
to  look  at  payback  period  or  ROI,  nor  does  management 
expect  a  direct  improvement  in  earnings  per  share. 

[Ref.  22] 

Keen  also  gives  a  representative  list  of  commonly 
cited  benefits  of  a  DSS.  This  list,  Table  2.2,  shows  that 
most  of  the  items  are  difficult  to  measure. 

Value  Analysis  as  suggested  by  Keen  is  illustrated 
in  Figure  2.11.  In  stage  one  the  designer  and  user  identify 
what  they  believe  to  be  possible  benefits  of  the  system. 
Then,  a  cost  threshold  is  determined  based  on  what  the  user 
would  be  willing  to  pay  to  attain  these  benefits. 


TABLE  2.2  DSS  BENEFITS 


1.  Increaa*  in  numbmr  of  altmrnativma  examined 

2.  Battar  undar standing  of  the  buainasa 

3.  Fast  raaponsa  to  unexpected  situations 

4 .  Ability  to  carry  out  ad  hoc  analysis 

5.  New  insights  and  laaming 

6 .  Improved  communication 

7 .  Control 

8 .  Cost  savings 

9 .  Battar  dacisions 

10.  Mora  affactiva  teamwork 

11 .  Tima  savings 

12.  Making  battar  usa  of  data  sourca 


If  a  prototype  can  be  constructed  while  staying 
within  the  bounds  of  the  cost  threshold,  then  the  project 
continues.  If  not,  the  project  ceases  before  any  funds  are 
committed.  Arbitrarily  choosing  benefits  may  result  in  a 
system  that  does  exactly  what  the  user  asked  it  to  do.  This 
may  not  be  what  the  user  needs  the  system  to  do.  It  is 
important  that  the  benefits  used  in  Value  Analysis  are  closely 
aligned  with  the  critical  success  factors  (CSF)  of  the  user 
and  organization. 

Goals  represent  the  end  points  that  an  organization 
hopes  to  reach.  Critical  success  factors,  however,  are 
the  areas  in  which  good  performance  is  necessary  to  ensure 
attainment  of  those  goals.  [Ref.  23] 
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Establish  Value: 


Define  operational  list  of  benefits: 

e.g.,  solves  urgent  business  problem, 
provides  a  flexible  tool  for  recurrent  analysis, 
makes  planning  data  quickly  accessible, 
saves  time  in  recurrent  ad  hoc  reporting 

v. 

Determine  Cost  Threshold: 

Define  maximum  one  would  be  ready  to  pay 
to  gain  the  benefits 

•  Determine  if  a  prototype  can  be  built 
-.that  delivers. the  necessary  capabilities 


Build  Version  0: 

Define  an  architecture  that  permits  the  full 
system  to  be  evolved  from  the  initial  Version  0. 

Define  routines  tor  prototype 

Assess  Prototype: 

Review  benefits;  revise  and  extend  list 
Review  desired  and  obtainable  capabilities 
Define  functional  capabilities  of  full 
system 

/ 

Establish  Cost  of  Version  I: 

How  much  will  the  full  system  cost? 

\ 

Determine  Benefit  Threshold: 

What  level  of  benefits  must  be  obtained 
to  justify  the  investment  in  the  lull 
system? 

What  is  the  likelihood  these  can  be 
|  obtained? 

Build  Version  1 

♦ 

Evolve  Version  N 

Review  usage,  evaluate  new  capabilities 
desired  or  obtainable 
Establish  cost 

Determine  benefit  threshold 


Figurs  2.11  Valus  Analysis  [Rsf.  22] 
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Stage  II  Stage  I 


Assuming  that  the  project  is  to  proceed,  the 
prototype.  Version  0,  is  constructed  and  then  evaluated  using 
Table  2.2  and  the  prototype  assessment  model  [Ref.  8]  shown 
in  Figure  2.12.  This  process  continues  indefinitely  as  the 
project  evolves. 

Value  analysis  works  well  with  an  adaptive  design 
philosophy.  It  encourages  prototyping  and  provides  a 
convenient  vehicle  to  monitor  whether  a  system  is  measuring 
up  to  expectations,  a  continual  evaluation  process. 

What  remains  to  be  seen  is  how  the  system  will 
evolve.  Do  the  techniques  identified  lend  themselves  to  an 
orderly  growth  process?  What  is  the  evolution  strategy  best 
suited  for  DSS/ES? 

2 .  Evolution 

Adaptive  design  technique  and  value  analysis  by  their 
nature  dictate  that  the  system  will  start  small,  usually  with 
a  prototype  and  continue  to  grow  in  size  and  capabilities  as 
possible  benefits  are  identified.  The  initial  prototype  will 
emerge  in  the  form  of  a  module  designed  to  solve  a  specific 
problem.  Adaptive  design  encourages  development  of  future 
modules  to  satisfy  user  requirements  as  they  are  identified. 
Each  proposed  module  should  undergo  the  archipelagian  process 
to  determine  feasibility. 
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Figure  2.12  Prototype  Assessment  Model 
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The  final  system  may  only  bare  a  slight  resemblance 
to  the  prototype  in  appearance  and  functions.  This  is 
contrary  to  the  maturing  process  in  the  traditional  life  cycle 
where  a  system  ages  and  is  maintained,  but  not  significantly 
modified.  There  will  be  cases,  particularly  if  the  system  is 
small  in  scope  and  easily  defined,  where  the  conventional  life 
cycle  approach  can  be  utilized  and  established  design 
procedures  may  be  appropriate. 

E.  SUMMARY 

Due  to  dramatic  improvements  in  computer  hardware  and 
reduced  costs,  computers  have  become  powerful  personal  tools. 
Now,  managers  are  utilizing  computers  in  decision  makin 
These  systems  are  referred  to  as  Decision  Support  and  Expert 
Systems . 

These  systems  differ  from  previous  information  systems 
such  as  Electronic  Data  Processing  which  focus  on  transaction 
processing  and  Management  Information  Systems  which  rely  on 
database  systems  for  report  generation.  A  DSS  incorporates 
a  model  subsystem  which  manipulates  data  in  the  database  often 
through  mathematical  algorithms.  An  ES  uses  inferencing 
techniques  to  reach  conclusions  about  information  stored  as 
rules  and  facts  in  its  knowledge  base. 
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There  are  marked  differences  between  a  DSS  and  an  ES  as 
to  structure,  type  of  software  and  even  appropriate 
environments.  However,  the  essential  difference  lies  in  their 
purpose.  A  DSS  is  built  strictly  as  an  assistant  to  the 
decision  maker.  This  is  done  primarily  through  ad  hoc  queries 
which  explore  various  alternatives .  An  ES  on  the  other  hand, 
provides  expertise  in  the  absence  of  an  expert.  Where  the  DSS 
responds  to  user  query,  an  ES  may,  when  a  need  exists  fcr 
additional  data,  query  the  user. 

Maintenance  control  is  a  decision  making  work  center  which 
performs  no  better  than  the  decision  makers  it  employs. 
Developing  and  retaining  "expert"  decision  makers  is  a 
continuing  problem.  The  authors  believe  that  the  scarcity  of 
"experts"  in  the  maintenance  control  environment  can  be 
mitigated,  throughout  Naval  Aviation,  with  DSS/ES 
implementation.  This  would  be  accomplished  by  the  system's 
ability  to  improve  the  "nonexpert's"  decision  making 
performance . 

Discussion  thus  far  has  focused  on  information  about 
decision  making,  DSS/ES  structure  and  design,  justification, 
evaluation  and  evolution.  Consideration  of  each  issue  is 
required  prior  to  DSS/ES  application  in  maintenance  control. 
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A  DSS/ES  designer  must  understand  the  factors  that  affect 
decision  making.  He  must  be  able  to  identify  the  ill 
structured  problems  of  the  decision  making  environment  to 
which  a  DSS  will  lend  support.  After  problem  identification, 
data,  models  and  heuristic  knowledge  bases  required  for 
decision  assistance,  can  be  determined  and  developed. 

ROMC  is  recommended  as  a  technique  that  will  help  the 
designer  to  identify  essential  features  of  a  DSS/ES  by 
adaption  of  the  user's  present  dss.  A  high  degree  of 
flexibility  is  needed  to  accommodate  systems  with  multiple 
users  of  varying  cognitive  styles.  ROMC  permits  such 
flexibility  in  its  use  of  representations  and  control 
mechanisms . 

The  design  of  a  DSS/ES  is  better  suited  to  an 
adaptive/prototype  style  of  development  vice  the  traditional 
"life  cycle"  approach.  This  is  primarily  due  to  the  user's 
inability  to  identify  requirements  from  the  beginning. 
Prototyping  and  adaptive  design  allows  for  system  modification 
and  evolution  due  to  changing  user  requirements  and  emerging 
technology . 

Managers  who  propose  the  implementation  of  a  DSS/ES  in 
their  organizations  often  have  difficulty  justifying  such  a 
system  if  a  "cost-benefit"  analysis  is  the  means  of 
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justification.  This  is  because  of  the  many  intangible 
benefits  in  the  analysis.  Justification  can  be  derived  using 
value  analysis  techniques  to  identify  and  evaluate  intangible 
benefits . 

Chapter  II  has  discussed  general  issues  involved  in  DSS/ES 
design  and  implementation.  Chapter  IV  will  describe  the  form 
these  issues  take  with  practical  application  to  maintenance 
control . 
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III.  THE  ENVIRONMENT:  MAINTENANCE  CONTROL 


Good  system  design  can  only  flow  from  a  thorough 
understanding  of  the  environment  for  which  a  DSS  is  being 
developed.  A  background  summary  of  maintenance  control's 
responsibilities  followed  by  a  scenario  depicting  typical 
problems  provides  a  view  of  the  environment.  The  objective 
is  to  identify  the  types  of  problems  the  Maintenance  Control 
Chief  (MCC)  must  deal  with  routinely.  This  will  establish  a 
reference  base  for  the  recommended  design  of  a  decision  making 
system . 

A.  MAINTENANCE  CONTROL:  BACKGROUND 

Modern  aviation  performs  in  a  complex  and  unforgiving 
technological  environment.  Consequently,  associated 
maintenance  activities  are  virtually  smothered  in  programs 
designed  to  ensure  quality  and  safety.  Solutions  to  problems 
which  fall  in  the  domain  of  such  programs  are  usually 
inflexible  and  handled  with  specific  procedures. 

To  acquire  appreciation  for  the  depth  of  knowledge 
required  by  an  "expert”  maintenance  controller,  Table  3.1 
lists  some  of  the  major  programs  involved  in  "programmed" 
decision  making  as  listed  in  the  OPNAVINST  4790. 2D.  [Ref.  24] 
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TABLE  3.1  COMMON  AVIATION  MAINTENANCE  PROGRAMS 


Naval  Aviation  Maintananca 
Parsonnal  Qualification  Standards 
Cartif ication/Licansing 
Training 

Analytical  Maintananca 
3-M  Raporting 
Fual  Survaillanca 
Oil  Analysis 

Aviators  Braathing  Ozygan  Survaillanca/Contamination 
Hydraulic  Contamination  Control 
Survaillanca  of  Nitrogan  Sarvicing/Equipmant 
Foraign  Objact  Damaga 
Tool  Control 

Corrosion  Pravantion/Control  Program 
Tira-Nhaal  Maintananca  and  Safaty 
Aircraft  Racaipt  and  Trans far 
Configuration  Managamant 
Waight  and  Balanca 
Spacial  Intarast  Aircraft 
Cannibalisation 

Prasarvation,  Shipmant  and  Storaga 

Haaring  Consarvation 

Ordnanca  Handling 

Support  Equipmant 

Issua  Priority  Systam 

Pack-Up  Kits 

Flight  Packats 

Aircraft  Log  Books 

Aircraft  Invantory  Racord 

Aaronautical  Equipmant  Sarvica  Racords 

Aircraft  Invantory  Raporting  Systam 

Aircraft  Engina  Accounting  Systam 

Compass  Calibration 

Aircraft  Armamant  Equipmant  Pool 


Many  of  the  subject  areas  listed  require  a  detailed  working 
knowledge.  Such  knowledge  is  the  sum  result  of  many  years 


association  with  naval  aviation  maintenance. 


From  the 


discussion  in  Chapter  II,  Simon  would  consider  such  problems 
to  be  structured  or  "programmed." 

Maintenance  control  is  the  focal  point  for  managing  the 
maintenance  of  material  assets  to  meet  mission  requirements. 
As  such  it  is  the  maintenance  department's  single  most 
important  work  center.  In  brief,  its  mission  is  accomplished 
through:  (1)  directing  all  scheduled  and  unscheduled 
maintenance  of  squadron  aircraft  (A/C);  (2)  assigning  the 
daily  maintenance  work  load;  and  (3)  establishing  work 
priorities.  Scheduled  maintenance  alone  involves  a  complex 
myriad  of  activities .  The  MCC  must  constantly  juggle 
decisions  involving  aircraft  assignments  to  fill  a  flight 
schedule.  He  must  not  only  consider  mission  necessities  but 
also  periodic  requirements  for  special  inspections  and 
maintenance  required  by  higher  directives  such  as  the 
OPNAVINST  4790  series.  (Complete  responsibilities  for  each 
maintenance  billet  and  work  center  are  delineated  in  Chief  of 
Naval  Operations  Instruction,  OPNAVINST  4790. 2D.)  [Ref.  24] 

The  maintenance  department's  organizational  chart  for  a 
Navy  squadron  is  shown  in  Figure  3.1.  The  Maintenance  Officer 
is  usually  an  04  to  05  who  has  overall  department  head 
responsibility.  His  right  hand  man  is  the  Maintenance 
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Figure  3.1  -  Squadron  Maintenance  Department 

Material  Control  Officer  (MMCO)  who  is  responsible  for  both 
the  maintenance  and  material  control  work  centers.  At  the 
enlisted  level.  Maintenance  Control  is  managed  by  the 
"Maintenance  Control  Chief"  (MCC) .  The  MCC  is  typically  an 
E7-E9  who  has  substantial  experience  in  the  maintenance  sphere 
and  a  reputation  for  being  an  accomplished  facilitator.  It 
is  at  this  level  in  the  maintenance  department,  where  the  vast 
majority  of  daily  production  decisions  are  made,  that  our 
DSS/ES  is  primarily  targeted. 
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B.  MAINTENANCE  CONTROL  SCENARIO 


The  following  scenario  is  used  to  help  describe  the 
problem  environment  and  is  only  one  example  of  the  many 
complex  issues  facing  maintenance  control  personnel.  It  gives 
a  representative  example  of  what  actually  takes  place  and  of 
the  decision  making  in  maintenance  control. 

It  was  1400  Friday  afternoon.  Senior  Chief  Foster  was 
filling  out  the  passdown  log  for  the  weekend  duty  section. 
Senior  Chief  Foster  was  proud  to  be  the  "Maintenance  Chief" 
of  VP-21.  He  now  ran  the  show  even  though  he  knew  his  boss, 
MMCO  LT  DuPuy,  would  forget  this  fact  from  time  to  time. 

The  Senior  Chief  was  filling  the  shoes  of  retired  Master 
Chief  Jack  Synder  who  had  retired  last  Wednesday.  Synder  had 
been  a  dynamic  force  in  the  maintenance  department  with  over 
thirty  years  aviation  maintenance  experience.  When  the  Master 
Chief  spoke — everybody  listened.  Synder  had  been  recognized 
as  among  the  elite  in  the  west  coast  P-3  community.  He  had 
often  been  tasked  by  the  Air  Wing  to  move  in  temporarily  at 
other  squadrons  and  help  "straighten  things  out."  Under 
Master  Chief  Synder' s  tutelage  VP-21  had  won  the  Golden  Wrench 
Award  the  last  two  years  and  was  credited  with  having  the  best 
corrosion  prevention  program  in  the  fleet.  He  was  the  best, 
but  after  33  years  he  had  hung  it  up. 


Master  Chief  Synder  had  hand  picked  Senior  Chief  Foster 
as  his  replacement.  The  Senior  Chief  was  a  true  professional. 
He  was  competent/  tireless,  dedicated,  and  devoutly  loyal. 
He  brought  with  him  22  years  of  maintenance  experience  with 
6  of  those  having  been  served  in  maintenance  control.  Synder 
had  been  impressed  with  the  Senior  Chief's  ability  to  work 
well  "under  fire"  and  to  anticipate  future  problems.  The 
Master  Chief  had  also  been  impressed  with  Foster's  ability  to 
handle  both  "assertive"  officers  and  "reluctant"  aircrew. 

This  Friday  afternoon  the  Senior  Chief  was  primarily 
concerned  with  Monday's  flight  schedule.  VP-21  had  been 
chosen  to  assist  with  a  CNO  project  analyzing  underwater 
acoustical  sensitivity  under  varying  ocean  conditions  such  as 
salinity,  temperature,  and  depth.  Much  of  the  project  was 
classified.  All  the  Senior  Chief  knew  was  that  both  the 
Maintenance  Officer  LCDR  Fastrack  and  the  MMCO  LT  DuPuy  made 
it  very  clear  that  on  Monday  a  fully  mission  capable  (FMC) 
aircraft  would  be  available  for  the  flight  with  another 
aircraft,  also  FMC,  standing  by.  This  was  a  high  visibility 
event  which  required  the  assistance  of  two  VIP's.  One  VIP  was 
from  the  CNO' s  Research  &  Development  staff  and  the  other  was 
a  professor  from  the  acoustical  laboratory  at  the  Naval 


Postgraduate  School . 


The  Senior  Chief  was  reviewing  the  status  of  his  air  force 
as  shown  by  the  Visual  Information  Display  (VID)  boards  on  the 
wall.  These  are  pocket  filled  boards  which  display 
maintenance  discrepancies  documented  against  each  aircraft  by 
work  center.  He  entered  the  following  notes  in  the  passdown 
log  for  ADI  Taylor.  Taylor  was  on  the  Maintenance  Control 
Watch  Bill  for  the  weekend  duty  section.  See  Table  3.2  for 
passdown . 

Petty  Officer  Taylor  was  the  Power  Plants  Supervisor.  An 
excellent  jet  engine  mechanic,  he  had  stood  the  Maintenance 
Control  Watch  several  times  before,  but  this  was  the  first 
time  flights  were  scheduled  while  he  stood  the  watch.  The 
squadron  was  behind  on  its  training  flights  and  wanted  badly 
to  get  a  Saturday  flight  out.  The  Senior  Chief  knew  Taylor 
was  a  good  man  who  had  handled  Maintenance  Control  well 
before.  However,  he  had  planned  to  drop  in  Saturday  afternoon 
just  to  see  how  things  were  going.  He  did  not  want  to  show 
up  first  thing  in  the  morning  as  he  knew  Taylor  would  sense 
a  lack  of  confidence. 
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TABLE  3.2  PASS DOWN  LOG 


A/C  Status  Passdown 


RD1 

BD2 

RD3 

RD4 

RD5 

RD6 

RD7 


FHC 
PMCM 
PHASE  D 

FHC 

PMCS 

PHASE  B 
SDLM 


Will  fly  Monday  on  "Spacial  Projacta" 
flight . 

Still  flying.  Work  off  raturn  gripas  as 
you  can. 

Phasa  inspaction  to  ba  f ini shad  this  PM. 
Parform  daily  inspaction  and  prapara  for 
chack  flight.  Bird  will  turn  around 
aftar  chack  flight  for  Nav.  hop. 

Usa  as  backup  for  "Spacial  Projects" 
flight  Monday. 

Hava  electricians  continue  to  work  on 
autopilot . 

Pull  into  hangar  to  begin  PHASE  B  Monday. 
A/C  still  at  SDLM  (Standard  Depot  Laval 
Maintenance)  undergoing  rework. 


RDl  had  been  the  squadron  workhorse.  Time  after  time  she 
had  come  through  and  performed  well  during  important  missions. 
For  this  reason  the  Senior  Chief  had  chosen  her  for  the 
special  projects  flight  Monday.  However,  RDl  had  a  high-time 
generator  on  the  number  two  engine.  They  were  already  well 
into  the  ten  percent  rule.  (This  is  a  rule  which  allows 
maintenance  managers  to  go  beyond  the  maximum  replacement 
hours  by  ten  percent  for  some  components . )  Twelve  hours 
remained  before  the  aircraft  would  have  to  be  grounded  or 
downed  for  maintenance.  RD4  was  presently  FMC  and  had  done 
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well  her  last  two  times  out.  Therefore,  RD4  was  selected  as 
the  backup. 

Saturday  morning  ADI  Taylor  was  in  at  0630  preparing  for 
the  0730  maintenance  meeting.  He  reviewed  Senior's  passdown 
notes  and  noted  the  flight  schedule  for  the  day  which  listed 
two  flights  both  scheduled  for  RD3.  The  flight  schedule 
listed  a  one  hour  check  flight  for  a  0900  takeoff.  The 
navigation  flight  was  a  turnaround  event  scheduled  for  six 
hours  with  a  1015  launch.  Taylor  knew  he  would  be  at  the 
squadron  all  day. 

At  0730  the  duty  section  mustered  in  maintenance  control 
for  the  meeting.  Petty  Officer  Taylor  briefed  the  duty 
section  on  the  flights  for  the  day  and  basically  let  the  shops 
work  on  what  they  felt  was  required.  He  told  the 
electricians,  known  as  AE's,  that  the  Senior  Chief  wanted  them 
to  work  on  RD5's  autopilot.  Just  before  the  meeting  broke  up 
Airman  Dalton,  a  member  of  the  phase  crew,  told  Taylor  that 
on  buttoning  up  RD3  yesterday  evening  they  were  missing  a 
screwdriver.  They  thought  they  knew  where  it  was  and  had 
planned  on  looking  for  it  first  thing  this  morning.  They 
would  have  notified  Maintenance  Control  yesterday  but  they 
knew  they  would  have  to  hang  around  until  they  found  it  and 
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they  had  to  come  in  today  anyway.  They  didn't  know  the  plan 
was  to  fly  the  aircraft  today. 

There  was  a  maintenance  instruction  which  covered  missing 
tools.  Taylor  had  read  it  long  ago.  As  a  supervisor  he  was 
well  aware  of  the  procedure--call  Maintenance  Control, 
Maintenance  Control  downs  the  airplane  until  the  tool  is 
either  found  or  the  inspection  team  headed  by  the  Quality 
Assurance  (QA)  Department  determines  the  tool  is  not  on  board 
the  aircraft.  He  notified  the  duty  section  QA  representative, 
AMS  2  Phillips.  He  told  Phillips,  "Hurry  up  and  get  an 
inspection  team  together  and  find  that  tool.  The  pilots  will 
be  in  any  time  now  to  start  their  preflight."  He  thought  he 
had  better  review  the  instruction.  Where  was  it?  Maintenance 
Control  keeps  a  copy  of  all  such  instructions ...  somewhere . 

A  half  hour  later  LCDR  Dave  Hustle  and  LT  Ross,  the  pilot 
and  copilot,  started  reviewing  the  Aircraft  Discrepancy  Book 
(ADB)  to  become  familiar  with  discrepancies  written  from  the 
last  ten  flights.  This  was  standard  procedure  and  a 
requirement  of  OPNAVINST  4790.  It  was  obvious  Mr.  Hustle  was 
not  happy  about  having  to  come  in  on  a  Saturday.  He  complained 
about  many  of  the  maintenance  sign  offs.  The  pilots  signed 
the  A  Card,  accepting  the  aircraft,  and  started  their 
preflight . 
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AMS 2  Phillips  entered  maintenance  control  and  said  they 
had  completed  a  thorough  inspection  of  RD3  and  had  not  found 
the  missing  screwdriver.  He  thought  he  had  better  call  his 
boss  Senior  Chief  Davies.  Phillips  returned  shortly  saying 
Mrs.  Davies  claimed  the  Senior  Chief  was  out  and  would  have 
him  call  as  soon  as  he  returned.  Taylor  pressed  Phillips  for 
a  determination  reminding  him  that  the  aircraft  was 
technically  down  with  a  crew  in  preflight.  After  a  strong 
reminder  from  Taylor  to  Phillips  that  Phillips  was  in  charge 
at  the  moment,  not  Senior  Chief  Davies,  Phillips  said  the 
aircraft  was  up  as  far  as  he  was  concerned.  He  did  not  think 
the  tool  had  been  left  on  the  aircraft.  At  1005  RD3  had 
"wheels  in  the  well." 

At  1015  Senior  Chief  Davies  called  maintenance  control. 
After  ADI  Taylor  briefed  him,  Davies  began  to  rant  and  rave 
about  proper  procedures.  He  shouted  that  only  the  Maintenance 
Officer  could  "up"  an  aircraft  if  the  tool  was  not  found. 
(Actually  the  instruction  called  for  a  decision  by  the  MO  or 
the  acting  MO,  the  next  in  command) .  He  further  stated  that 
if  the  MO  could  not  be  contacted,  the  aircraft  would  have  to 
be  recalled  immediately. 

Taylor  then  called  Senior  Chief  Foster  rather  than  LT 
Depuy,  who  was  the  acting  MO.  Mrs.  Foster  said  that  he  was 
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running  errands  and  planned  to  stop  by  the  squadron  before 
returning  home.  Petty  Officer  Taylor  decided  to  recall  RD3 . 

Twenty  minutes  later  RD3  was  on  deck.  After  issuing  a 
verbal  lashing,  LCDR  Hustle  demanded  to  know  which  aircraft 
they  were  now  going  to  assign  on  the  navigation  hop.  He  was 
not  going  to  wait  around  all  day  for  RD3  and  wanted  another 
aircraft.  ADI  Taylor  assigned  him  RD5 .  Seeing  the  aircraft 
had  an  autopilot  gripe,  Hustle  exploded.  He  was  not  going  to 
"bore  holes  in  the  sky  for  five  to  six  hours  without  an 
autopilot."  He  knew  RD1  was  a  good  plane  and  he  demanded  it. 
RDl  was  airborne  fifty  minutes  later. 

At  1400  Senior  Chief  Foster  entered  maintenance  control. 
After  Taylor's  brief,  Foster  took  time  to  regain  his  composure 
and  think  about  the  situation.  RDl  was  now  out  of  the  picture 
for  Monday.  There  would  not  be  enough  hours  left  to  conduct 
the  mission  due  to  the  generator  drop  dead  time.  That  meant 
RD4  would  have  to  be  the  primary.  RD3  still  needed  a  check 
flight  and  that  meant  one  of  the  remaining  PMC  birds  would 
have  to  come  up  to  FMC  status  by  Monday  per  MO  orders. 

AE2  Johnson  then  walked  into  the  work  center.  He  wanted 
to  know  if  he.  Walker,  and  Smith,  the  remainder  of  the  AE  duty 
section,  could  secure  for  the  day.  He  explained  that  neither 
he  nor  the  others  knew  anything  about  the  autopilot  and  had 
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basically  just  wasted  the  entire  day  trying  to  fix  it.  He 
further  explained  that  RD2  was  partial  mission  capable  (PMC) 
for  his  shop  only,  had  they  worked  on  it  they  probably  could 
have  brought  its  status  up  to  FMC. 

At  1500  the  MO,  LCDR  Fastrack,  received  the  brief  from  LT 
DePuy.  Fastrack  declared  Sunday  a  full  work  day  until  the 
squadron  was  caught  up  and  ready  for  Monday.  Senior  Chief 
Foster  was  told  that  he,  LT  DePuy,  and  LCDR  Fastrack  were  to 
brief  the  skipper  Sunday  at  0730  sharp  as  to  why  maintenance 
was  "so  screwed  up." 

Fortunately  what  is  described  is  not  the  norm  but  it  is 
a  realistic  example  of  occurrences  that  do  arise  from  time  to 
time.  With  the  aid  of  a  DSS/ES  Petty  Officer  Taylor  could 
have  accessed  the  procedures  to  properly  handle  the  missing 
tool.  The  .missing  tool  was  a  programmed  situation  with  little 
leeway  for  decision  making.  However,  when  the  instruction 
could  not  be  found.  Petty  Officer  Taylor  and  Senior  Chief 
Davies  began  making  erroneous  decisions.  As  noted  the  missing 
tool  instruction  specified  that  the  acting  MO  will  make  the 
decision  on  whether  to  recall  or  not. 

Taylor  is  not  to  be  faulted  for  errinq  on  the  side  of 
safety  for  recalling  RD3 .  However,  while  the  aircraft  should 
have  never  been  launched,  a  thorough  QA  inspection  had  been 
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conducted  as  required.  The  MO  (or  the  acting  MO)  should  have 
been  afforded  the  chance  to  decide  if  a  recall  was  necessary 
since  the  critical  part  of  the  procedure  had  been  handled 
properly . 

Petty  Officer  Taylor  made  another  poor  decision  in 
assigning  RDl  to  LCDR  Hustle.  Under  stress,  Taylor  was 
slightly  overwhelmed  and  failed  to  notice  the  limited  hours 
remaining  on  RDl.  An  ES  incorporating  aircraft  scheduling 
would  have  flagged  RDl  as  a  "high  time"  aircraft.  This  would 
have  provided  the  argument  needed  to  convince  LCDR  Hustle  that 
the  training  flight  should  be  cancelled  to  save  RDl  for  its 
operational  commitment  on  Monday. 

Similarly,  if  Senior  Chief  Foster  had  had  the  benefit  of 
a  DSS/ES  the  previous  evening,  he  would  not  have  insisted  the 
AE's  work  on  RD5's  autopilot.  He  did  a  poor  job  of  JCN 
prioritization.  A  database  showing  the  qualifications  of  duty 
section  personnel  would  have  revealed  this  deficiency. 

As  this  scenario  demonstrates,  a  few  mistakes  and  wrong 
decisions  can  easily  bring  a  squadron's  smooth  operation  to 
a  grinding  halt.  It  is  highly  unlikely  that  the  individuals 
concerned  will  make  the  same  mistakes  again.  However,  these' 
persons  will  most  likely  only  be  in  the  squadron  for  two  more 
years  on  average. 
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Just  as  a  wealth  of  knowledge  and  skill  departed  with 
Master  Chief  Synder,  it  will  depart  again  when  these  sailors 
are  transferred.  A  DSS/ES  designed  to  capture  and  retain 
their  expertise  will  go  far  in  preventing  others  from  learning 
the  same  lessons  the  hard  way. 
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IV.  DSS/SS  DESIGN  FOR  NAVAL  AVIATION  MAINTENANCE  CONTROL 


The  initial  DSS/ES  design  must  have  a  set  of  guiding 
standards  for  construction  and  development.  These 

specifications  should  establish  the  "need  for",  the 
"ingredients  of"  and  the  "how  to"  of  system  design.  Chapter 
IV  addresses  the  primary  thesis  research  question  regarding 
definition  of  design  criteria  for  a  DSS/ES  in  maintenance 
control .  The  subsidiary  research  questions  concerning  system 
design,  justification  and  how  the  system  is  to  evolve  are  also 
answered . 

A.  DESIGN  CRITERIA 

The  following  criteria  have  been  identified  as  applicable 
for  the  development  of  a  DSS/ES,  for  any  environment.  Some 
may  not  apply  in  all  cases,  but  most  are  general  enough  in 
nature  to  permit  broad  application.  The  criteria  are: 

1.  Identify  the  need  for  a  DSS/ES. 

2.  Identify  the  decision  making  factors. 

3.  Identify  the  present  dss. 

4.  Identify  the  ill-structured  problems. 

5.  Identify  the  problem  related  data. 

6.  Identify  the  required  problem  solving  models. 

7.  Identify  the  required  heuristic  rule  bases. 
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Each  of  these  standards  applicability  with  regard  to 
maintenance  control  is  discussed  in  the  following  paragraphs. 

1.  Need  for  a.  DSS 

Not  all  problem  environments  require  or  would  even 
benefit  from  a  computerized  decision  support  system. 
Problems  which  are  easily  solved  through  a  common  sense 
approach  or  through  rote  memorization  of  procedure,  will  not 
require  the  power  of  computer  assistance.  If  systems  were 
installed  in  these  environments,  they  most  likely  would  not 
be  used. 

This  is  not  the  case  for  the  maintenance  control 
domain.  Maintenance  control  appears  to  be  a  fertile  area  for 
the  application  of  DSS/ES.  The  decision  making  environment 
satisfies  Simon's  DSS  requirement  for  complexity  in  that  the 
user,  the  MCC,  is  confronted  with  problems  lacking  in 
structure.  The  lack  of  structure  is  caused  in  maintenance 
control  by  the  shortage  of  experienced  decision  makers 
(experts) ,  operational  pressure  and  the  stresses  induced  by 
time  limitations.  (Studies  have  shown  that  decision  makers 
under  stress  often  perform  less  efficiently.  Stress  decreases 
their  ability  to  process  information.)  [Ref.  25] 

Maintenance  control  is  a  problem  environment  in  which 
decision  makers  are  confronted  with  ill-structured  problems 
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and  can  realize  benefits  through  the  employment  of  a 
computerized  decision  support  system. 

2.  Decision  Making  Factors 

Inputs/outputs,  resources,  user  cognitive  style  and 
organizational  decision  making  pressures  are  all  factors  which 
affect  decision  making.  The  recognition  of  these  factors  and 
the  varying  roles  they  play  in  making  decisions  will  greatly 
assist  the  engineer  in  system  design, 
a.  Inputs  and  Outputs 

All  decision  processes  are  spurred  through  some 
form  of  stimuli  (input) ,  with  the  intention  of  achieving  some 
goal  (output) .  To  design  a  decision  support  system  which  will 
assist  the  decision  maker,  the  inputs  and  outputs  must  be 
identified . 

Figure  4.1  shows  the  basic  inputs  which  feed  into 
maintenance  control  are  "maintenance  discrepancies"  initiated 
either  by  the  maintainers  themselves  or  the  aircrew,  and  the 
"flight  schedule"  which  represents  mission  tasking.  The 
processes  involved  include  assigning  and  prioritizing  the 
JCN's  among  the  various  work  centers.  The  two  outputs  of 
maintenance  control  are  repaired  aircraft  and  aircraft 
assignments . 
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Schedule  Changes  Weather  Local  Restraints 


Special  Tasking  Commanding  Officer  Direction 


Figure  4.1  The  Maintenance  Control 
"System"  and  Environment 

Environmental  factors,  as  previously  defined  by 
Turban,  are  elements  over  which  the  MCC  has  little  control, 
yet  which  affect  his  inputs  and  outputs.  Such  elements  would 
include;  (1)  special  direction  by  his  superiors  which  might 
dictate  aircraft  assignment  or  repair  priorities;  (2)  special 
tasking  due  to  requirements  for  technical  directive 
incorporation  which  may  have  to  be  complied  with  immediately; 
(3)  schedule  changes  of  the  flight  schedule  or  of  upcoming 
deployments;  (4)  local  restraints  such  as  a  Naval  Air 
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deployments;  (4)  local  restraints  such  as  a  Naval  Air 
Station's  policy  which  might  prohibit  high  power  engine  checks 
for  maintenance  purposes  after  certain  hours  of  the  day;  and 
(5)  the  weather  which  might  force  some  maintenance  actions  to 
be  performed  in  an  aircraft  hangar. 

This  system  view  provides  a  perspective  from  which 
to  define  the  inputs  and  goals  of  maintenance  control  and  the 
external  factors  which  affect  them. 
b .  Rasourcma 

The  engineer  must  identify  the  resources  the 
decision  maker  has  at  his  disposal  for  solving  problems.  If 
maintenance  control's  main  goal  or  output  is  repaired 
aircraft,  what  resources  are  involved  in  the  repair? 

The  authors  have  identified  five  resource  groups 
about  which  the  MCC  must  be  constantly  appraised  if  changes 
occur.  If  resource  availability  changes,  this  will  affect 
repair  capability  and  subsequently  affect  work  priorities. 
These  resources,  or  objects,  may  be  represented  in  semantic 
net  fashion,  as  discussed  by  Harmon  and  King.  [Ref  15]  See 
Figure  4.2. 
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Figure  4.2  -  Maintenance  Performance  Ingredients  Of 
The  Problem  Environment 
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Semantic  nets  consist  of  objects,  attributes,  and 
values.  As  shown,  our  main  object,  the  aircraft  discrepancy, 
will  call  to  mind  the  possible  use  of  five  major  resources  or 
attributes.  Each  attribute  has  assorted  possible  values.  For 
instance,  requirement  for  hangar  facilities  may  trigger  a 
quick  review  of  its  values,  e.g.  the  need  for  various  forms 
of  power,  lighting,  ample  space,  heat,  etc. 

The  efficient  and  effective  management  of  these 
five  attributes  is  more  of  an  art  than  a  science.  It  is  an 
art  primarily  developed  through  experience.  The  MCC  expert 
develops  his  own  heuristic  set  of  rules  from  which  to  judge 
and  implement  courses  of  action  and  decisions, 
c.  Cognitive  Style 

The  system  engineer  should  evaluate  the  importance 
of  cognitive  style  to  his  system.  Each  decision  maker 
requires  information  upon  which  to  base  decisions  and  may  vary 
in  his  determination  as  to  what  information  should  be  sought 
and  how  it  should  be  formatted.  Therefore,  slight  variations 
in  cognitive  styles  are  to  be  expected  among  the  many 
maintenance  controllers  performing  throughout  Naval  Aviation. 

This  variety  can  only  be  accommodated  through  a 
design  with  maximum  flexibility.  A  DSS/ES  in  maintenance 
control  should  afford  the  user  multiple  options  for  data 
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retrieval  and  display.  Full  use  of  menus,  default  options, 
color,  sound  and  even  mouse  control  accessories  should  be 
considered . 

d.  Organisational  Decision  Making 

The  design  engineer  may  consider  the  affect  of 
organizational  pressures  on  decision  making  of  far  more 
concern  than  user  cognitive  style.  This  is  true  in 
maintenance  control  where  many  of  the  decisions  are  the  result 
of  SOP  application.  Because  there  are  variations  in  some  SOPs 
from  one  command  to  another  a  successful  system  will  have  to 
be  flexible  enough  to  work  in  various  command  climates. 

A  decision  support  system  for  maintenance  control 
will  require  all  decision  related  instructions  pertaining  to 
the  targeted  DSS/ES  problems  to  be  stored  as  database  text 
files . 

3.  Present  "das" 

In  computerized  system  design  it  is  necessary  to 
identify  all  of  the  present  decision  making  tools  used  by  the 
decision  maker.  These  tools  are  considered  the  MCC's  dss  as 
defined  by  Huber  [Ref.  7].  In  all  Naval  Aviation  Maintenance 
Control  work  centers,  MCC's  inherit  a  dss,  typically  involving 
the  items  shown  in  Figure  4.3. 
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Item  1,  the  Visual  Indication  Display  (VID)  Board  is 
used  to  display  and  organize  the  maintenance  actions,  or 
gripes,  associated  with  a  particular  aircraft.  The  gripes  are 
organized  by  a  Job  Control  Number  (JCN)  and  assigned  to  the 
required  shop.  Each  gripe  will  be  in  one  of  three  states;  in 
work,  awaiting  maintenance,  or  awaiting  parts.  Gripes  of  such 
serious  nature  as  to  prevent  flight  are  marked  in  red. 

Item  2,  the  scroll  box,  is  used  to  lay  out  scheduled 
commitments  and  best  guess  plans  for  performing  future 
scheduled  maintenance.  Such  things  as  phase  inspections, 
incorporation  of  required  technical  directives  and  periodic 
corrosion  work  are  scheduled  on  the  box  in  calendar  format  by 
aircraft . 

Item  3,  the  radio,  is  obviously  used  as  a  real  time 
device  for  information  collection  directly  from  the  repair 
personnel  at  the  aircraft  concerning  the  present  status  of  a 
repair  action. 

Item  4,  the  intercom,  is  used  for  direct  communication 
between  maintenance  control  and  all  squadron  maintenance  shops 
including  quality  assurance  and  material  control. 

Item  5,  the  Pass  Down  Log,  is  the  usual  night 
check/day  check  feedback  on  the  success  of  the  shift  and 
\  direction  for  the  oncoming  shift  on  particular  gripes. 
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Figure  4.3  -  Present  das 
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Item  6,  Flight  Schedule,  tells  maintenance  control 
what  its  operational  tasking  is  for  the  day.  The  Maintenance 
Chief  must  ensure  that  his  assets,  squadron  aircraft,  are 
assigned  in  the  most  efficient  manner  possible  to  meet  the 
flight  schedule  requirements. 

Item  7,  Functional  Check  Flight  Matrix,  provides 
information  as  to  which  completed  maintenance  actions  will 
require  a  aircraft  maintenance  check  flight  by  a  qualified 
check  pilot  before  it  can  be  scheduled  for  normal  operation. 

Item  8,  Aircraft  Discrepancy  Book,  provides  a 
historical  record  of  maintenance  actions  on  a  particular 
aircraft . 

Item  9,  Mission  Essential  System  Matrix,  lists  the 
systems  required  on  a  particular  aircraft  type  to  perform  a 
specific  mission. 

Item  10,  Naval  Aviation  Maintenance  Program 
(OPNAVINST-4790  series) ,  is  referred  to  as  the  maintenance 
"Bible".  It  is  a  5  volume  publication  which  spells  out 
specific  do's  and  don't' s  for  the  entire  field  of  Naval 
Aviation  Maintenance. 

Item  11,  Periodic  Maintenance  Information  Cards,  list 
all  aircraft  components  which  are  under  specific  inspection 
and  removal  plans  for  aircraft  types. 


Item  12,  Maintenance  Instructions  and  Standard 
Operating  Procedures,  is  an  attempt  by  squadrons  to  summarize 
other  required  directives  into  a  condensed  readable  form  for 
quick  reference,  as  well  as  detailing  specific  guidance  by  the 
Commanding  Officer. 

4 .  Problem  Identification 

DSS/ES  are  designed  to  aid  decision  makers  with  semi- 
structured  problems.  Therefore,  before  design  begins,  system 
engineers  and  users  must  identify  the  problems  appropriate  for 
a  DSS/ES.  After  identification  of  the  semi-structured 
problems,  engineers  and  users  select  which  problems  will  be 
targeted  for  DSS/ES  solution. 

Decision  making  in  maintenance  control  may  seem 
straightforward  and  routine,  especially  considering  the 
abundance  of  written  guidance.  Using  Huber's  model  of 
decision  making,  maintenance  control  fits  in  the  "programmed 
model"  definition.  Here,  decision  making  is  preprogrammed  by 
written  or  verbal  guidance  requiring  little  ingenuity  or 
resourcefulness  on  the  part  of  the  decision  maker.  Much  of 
the  military  decision  environment  fits  into  the  Programmed 
Model  mold.  One  reason  this  is  a  necessity  is  because  of  high 
personnel  turnover  rates. 


However,  the  program  model  does  not  describe  any 
organization  in  its  entirety,  including  maintenance  control. 
As  the  scenario  in  Chapter  III  has  shown,  even  in  an 
environment  heavily  influenced  by  '’programmed"  decision 
making,  uncertainty  abounds  and  costly  decision  errors  are 
made.  In  fact,  if  some  of  the  routine  decision  making 
processes  that  typically  occur  in  maintenance  control  are 
examined  and  placed  in  Gorry  and  Scott-Morton' s  framework, 
many  fall  into  the  semi-structured  realm  as  shown  in  Figure 
4.4. 

As  shown,  item  number  4,  JCN  assignment,  is  a  well 
structured  task.  A  particular  discrepancy  will  fall  under  the 
cognizance  of  a  certain  shop.  For  example  a  radar  system 
discrepancy  will  be  assigned  to  the  avionics  branch  for 
repair,  a  structured  operational  decision. 

Conversely,  item  number  5,  assigning  the  daily 
workload  in  the  form  of  prioritizing  JCNs,  requires  more 
heuristics  and  decisions  begin  to  fall  in  the  semi-structured 
realm.  Uncertainty  arises  from  several  factors.  Which 
aircraft  is  being  pushed  to  meet  tomorrow's  flight  schedule? 
Which  missions  will  require  certain  systems  to  be  up  and 
running?  How  does  one  system's  discrepancy  affect  another 
system?  Which  personnel  are  on  board  with  the  required 
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Figure  4.4  Decision  Framework 


expertise  in  tonight's  shift?  It  does  little  good  to  assign 
a  particular  discrepancy  as  a  shop's  highest  priority  if  the 
people  with  the  requisite  skills  are  not  available  to  perform 
the  task. 

Borrowing  a  part  (cannibalization)  from  a  known  good 
system  to  replace  a  bad  part  in  another  aircraft  is  often  a 
routine  consideration  for  a  Maintenance  Chief.  Yet  certain 
constraints  may  make  decisions  which  are  typically  toutine 
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for  the  decision  maker  non-routine.  They  therefore  become 
semi-structured  or  un-st ructured .  For  example,  if  supply  does 
not  have  a  replacement  part  for  a  faulty  item  and  the  part  is 
necessary  for  certain  mission  performance,  then 
cannibalization  is  normally  justified.  But,  in  a  case  where 
the  cannibalizing  of  the  part  may  result  in  damage  to  the  part 
a  judgement  has  to  be  made  based  upon  the  risk  of  damage.  If 
the  risk  of  damage  is  high,  the  result  could  be  two  down 
aircraft.  In  such  a  case  a  strong  argument  against 
cannibalization  can  be  made. 

As  Figure  4.4  shows  there  are  a  significant  number  of 
decision  areas  in  maintenance  control  that  fall  in  the  semi- 
structured  range.  Such  problems  will  benefit  from  an 
effective  DSS/ES. 

5.  Relevant  Data  Identification 

Only  after  the  particular  problems  have  been  targeted 
for  solution  will  it  become  clear  which  data  is  needed  for 
problem  solution.  Once  the  necessary  data  is  identified  the 
engineer  has  defined  the  necessary  contents  of  his  database. 
For  instance,  if  support  is  sought  for  cannibalization 
decisions,  all  cannibalization  actions  and  related 
instructions  would  be  required  data.  The  instructions  will 
ensure  that  procedures  are  properly  followed  while  access  to 
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all  cannibalization  actions  ensures  that  the  MCC  will  consider 
cannibalization  rates  when  he  makes  his  decision.  Another 
example  is  the  problem  of  scheduled  maintenance.  Scheduled 
maintenance  requirements  are  dictated  by  aircraft  hours  flown. 
Therefore,  flight  hours  consumed  per  aircraft  will  have  to  be 
captured,  summed  and  stored.  For  each  problem  there  are 
similar  pieces  of  data  that  must  be  identified. 

6 .  Decision  Making  Modal* 

It  now  remains  for  the  design  engineer  to  assist  the 
human  decision  maker  by  developing  decision  making  models. 
The  criteria  developed  thus  far  would  be  necessary  for  the 
development  of  a  MIS  as  well  as  a  DSS/ES,  but  when  algorithmic 
processes  are  introduced,  information  systems  are  transformed 
into  decision  support  systems. 

As  an  example.  Figure  4.4  identified  scheduled 
aircraft  maintenance  as  a  semi-structured  problem  for  which 
a  decision  support  system  would  provide  user  assistance. 
After  the  problem  and  required  data  have  been  identified  it 
becomes  a  matter  of  what  algorithmic  procedure  should  be 
developed  to  provide  the  best  solutions  to  problems. 

The  problem,  scheduled  maintenance,  deals  with 
completion  of  required  aircraft  and  component  inspections. 
Some  requirements  include  removal  or  installation  of  new 
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systems  or  components  and  are  usually  based  on  consumption  of 
flight  hours,  e.g.,  the  aircraft  with  the  high  time  generator 
in  the  Chapter  III  scenario.  Most  scheduled  maintenance 
requirements  contain  a  factor  of  flexibility  such  as  the  10% 
rule  which  allowed  the  example  aircraft  to  exceed  the  maximum 
flight  hours  permitted  by  10%  before  generator  removal.  These 
requirements  are  published  in  such  directives  as  the  OPNAVINST 
4790  for  all  naval  aircraft,  and  the  PMIC,  discussed  in 
Chapter  II  for  an  aircraft  type. 

Most  guidance  will  be  in  the  form  of  flight  hours 
flown.  However,  in  some  cases  requirements  are  based  on 
calendar  days  or  hours  not  flown,  e.g.,  daily  inspection 
requirements.  (Of  course  any  special  guidance  through  Type 
or  Wing  Commanders  would  also  have  to  be  programmed . ) 

Scheduled  maintenance  becomes  complicated  when 
attempting  to  ensure  the  maximum  material  availability  during 
predicted  peak  operating  periods.  Holidays,  deployments, 
assignments  of  the  "ready  alert"  status  are  all  planning 
factors  which  must  be  considered. 

A  model  involving  scheduled  maintenance  will  require 
the  ability  to  perform  arithmetic  operations.  These 
operations  will  include  the  tracking  and  summation  of  aircraft 
flight  hours  per  aircraft.  Such  a  model  in  a  DSS  would  easily 
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permit  maintenance  managers  the  ability  to  access  the  phase 
inspection  requirements  for  all  aircraft  during  the  next  month 
based  on  predicted  flight  hours.  With  this  information  the 
managers  may  elect  to  complete  some  inspections  early, 
anticipating  heavy  operations  in  the  near  future.  Also,  such 
information  will  allow  material  control  supervisors  to  plan 
ahead  by  ordering  extra  "phase  kits". 

These  decision  making  models  must  be  capable  of 
processing  data  relevant  to  maintenance  control,  the  output 
must  conform  to  organizational  decision  making  constraints  and 
results  should  reflect  a  satisfactory  solution  to  the  targeted 
problems . 

7 .  SS  Knowledge  Base 

Some  semi-structured  problems  in  Figure  4.4  do  not 
lend  themselves  to  mathematical  solution,  e.g.,  prioritizing 
JCNs .  The  order  that  aircraft  discrepancies  should  be  worked 
is  a  daily  puzzle  which  if  approached  incorrectly  will  induce 
inefficient  use  of  available  resources.  McCaffrey  discussed 
the  approach  to  this  problem  in  the  context  of  an  expert 
system  with  a  heuristic  knowledge  base  incorporating  the  rules 
of  thumb  an  expert  uses  in  making  decisions.  These  heuristic 
rules  are  searched  through  chaining  and  inferencing  techniques 
to  arrive  at  a  solution.  If  ADI  Taylor  had  access  to  such  a 
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knowledge  base  he  would  have  prevented  shop  personnel  from 
establishing  their  own  priorities.  Shop  personnel  are  often 
unaware  of  the  big  picture  and  often  direct  their  attention 
to  "favorite  gripes."  If  not  guided  by  maintenance  control, 
material  availability  can  suffer. 

The  criteria  specified  in  this  section  provide  the 
design  engineer  with  the  raw  materials  necessary  for  system 
design.  First  he  has  established  a  need  for  the  DSS/ES. 
Next,  an  understanding  of  decision  making  factors,  the  present 
dss  and  the  problems  allows  him  to  conceptualize  the 
environment.  Finally,  problem  related  data  can  be  processed 
with  applicable  decision  making  models  or  heuristic  rule  bases 
to  arrive  at  a  solution.  These  raw  materials  are  used  with 
ROMC  to  begin  actual  system  design. 

B.  DESIGN  FRAMEWORK 

ROMC  provides  a  framework  to  delineate  system 
capabilities.  By  showing  the  characteristics  in  the  form  of 
Representations,  Operations,  Memory  Aids  and  Controls,  the 
designer  can  grasp  what  the  proposed  system  will  look  like. 
ROMC  is  also  used  to  identify  specifications  for  the  Dialog, 
Data  and  Model  (DDM)  paradigm.  To  compile  attributes  for  a 
system  the  designer  must  conduct  extensive  interviews  and 


80 


observe  the  decision  maker  in  his  work  environment.  Actual 
observation  is  beyond  the  scope  and  time  constraints  of  this 
thesis  so  representative  examples  have  been  provided  from  the 
authors'  personal  experiences.  Figure  4.5  shows  Sprague  and 
Carlson's  ROMC  method  as  it  is  applied  in  the  aviation 
maintenance  control  environment. 

1 .  Representation* 

When  the  decision  maker  envisions  a  problem  with 
aircraft  he  sees  them  as  either  UP  or  DOWN.  A  common  practice 
in  maintenance  control  is  to  have  displays  showing  an  aircraft 
as  either  green  (UP)  or  red  (DOWN)  .  In  applying  the  ROMC 
design  method  a  computer  screen  should  also  be  capable  of 
presenting  red  and  green  aircraft  figures  on  the  screen. 

It  can  be  argued  that  providing  the  decision  maker 
with  pictures  of  airplanes  does  not  make  his  job  any  easier 
as  he  already  has  this  aid  available.  This  example  is  used 
only  to  show  that  the  DSS  will  continue  to  provide  the  user 
with  the  aids  he  is  currently  using. 

There  are  other  conceptualizations  that  exist  only  as 
mental  images.  For  example,  when  the  shops  report  estimated 
time  to  repair  a  discrepancy,  the  MCC  forms  an  imaginary  time 
line  in  his  head.  This  is  easy  enough  if  there  is  only  one 
job  being  performed  on  one  aircraft.  Unfortunately  the  norm 


81 


is  that  numerous  jobs  are  being  performed  on  multiple  aircraft 
and  these  tasks  are  often  interrelated.  A  representation  on 
the  computer  screen  in  the  form  of  a  Gantt  chart  would  help 
the  decision  maker  retain  the  big  picture  avoiding  confusion 
about  when  each  job  will  be  finished. 

2 .  Operations 

The  DSS  must  also  have  certain  operational  features. 
Figure  4.5  shows  a  partial  list  of  necessary  capabilities  such 
as  a  database  query  function  to  retrieve  status  of  parts 
information  and  the  ability  to  prioritize  work  on  aircraft 
( JCN  prxoritization) .  An  Expert  System  capacity  can  be  used 
to  select  aircraft  for  assignment  to  a  flight  schedule  based 
on  heuristic  rules  of  expected  time  required  to  fix  a 
discrepancy  or  the  likelihood  that  a  part  procured  through 
cannibalization  will  correct  a  discrepancy.  An  ES  shell  can 
also  be  programmed  for  use  as  an  on-screen  checklist.  This 
is  particularly  useful  in  providing  guidance  for  the  user 
about  procedures  from  instructions  for  incidents  such  as  lost 
tools  or  fuel  spills. 

ROMC  operations  help  describe  the  model  component  of 
the  DDM  paradigm.  A  linear  programming  model  will  be  applied 
to  provide  optimization  capability  necessary  for  planning  long 
term  scheduled  maintenance,  aircraft  assignment  to  the  flight 
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schedule  and  personnel  shift  assignments.  A  heuristic  rule 
based  model  is  applicable  for  directing  unscheduled 
maintenance  and  JCN  prioritization. 

Another  function  of  operations  is  to  be  able  to  query 
a  database.  Because  much  of  the  data  needed  for  the  models 
will  be  stored  in  the  NALCOMIS  database,  the  system  must  be 
built  with  NALCOMIS  compatibility  as  a  consideration. 

3.  Memory  Aids 

A  decision  maker  in  any  given  environment  has  certain 
tools  to  help  keep  track  of  necessary  information  used  to 
arrive  at  a  solution.  It  is  no  different  in  maintenance 
control.  The  MCC  makes  extensive  use  of  tools  such  as  a 
passdown  log  to  keep  track  of  tasking,  a  scheduled  maintenance 
planning  chart,  and  a  multitude  of  instructions  guiding  him 
on  proper  procedures. 

These  tools  or  memory  aids  while  critical  for  proper 
job  performance  are  often  hard  to  find,  cumbersome  to  use  and 
sometimes  difficult  to  understand.  A  misplaced  passdown  log 
can  be  an  inconvenience,  and  in  some  circumstances  can  bring 
the  maintenance  effort  to  a  halt.  As  shown  in  Chapter  III  the 
inability  to  quickly  find  and  refer  to  an  instruction  can 
result  in  chaos.  A  DSS  constructed  to  provide  easy  access  to 
memory  aids  will  mitigate  these  problems. 
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Memory  aids  include  components  identified  as  relevant 
to  the  present  dss  and  consisting  of  the  passdown  log,  scroll 
box,  FCF  matrix,  MESM  and  ADB .  These  items  are  held  in 
various  forms  and  used  differently.  For  example,  if  a 
spreadsheet  aids  in  the  manipulation  of  scroll  box  data,  this 
information  will  be  held  in  a  spreadsheet  file.  A  note  pad 
allows  the  user  to  record  passdown  log  information  and  a 
library  function  gives  access  to  various  instructions,  both 
will  be  maintained  in  text  files.  Other  information  such  as 
outstanding  discrepancies  against  aircraft  will  be  held  in 
database  files. 

Design  of  memory  aids  as  pull-down  screens  will  give 
the  user  easy  access  to  virtually  any  reference  he  needs.  The 
user  can  work  on  a  task  and  bring  in  references  as  required 
without  interrupting  his  work.  Careful  attention  to  providing 
effortless  retrieval  of  information  will  do  much  to  guarantee 
use  of  the  system.  Memory  aids  should  be  powerful  and  promote 
convenience  of  system  use. 

4 .  Control  Hochanisms 

On  line  help,  default  values  and  menu  displays  are 
particularly  helpful  in  orienting  new  users  to  a  system. 
These  control  mechanisms  are  important  in  that  they  make 
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DEC I S I OH  MAKER’S  USE 


1.  Conceptualizations 
-UP/DOVH  Airplanes 

—Hangar  Space 

—Time 


-People  (qual/quan) 

-Parts  (availability) 

-Tools  (availability) 
-Flight  Schedule 


2.  Different  Decision-Making 
Processes  and  Decision  Types 
—Gather  data  on  Gripes, 
Personal  Qualifications, 
Parts,  Tools  and  Test 
Equipment,  and  * 
Facilities 

-Compare  Alternatives 


3.  A  Variety  of  Memory  Aids 
—Passdown  Log 
-Scroll  Box 
-FCF  Matrix 
-MESM 
— ADB 


4.  A  Variety  of  Styles,  Skills 
and  Knowledge  Applied  Direct 
Personal  Control 
-4790 
-MI /SOP’s 
— PMIC 
-TD’s 


DSS  PROVIDES 


1.  Representations 
-Miniature  Airplanes 
(red/green) 

-Hangar  Floor  Plan 
w/utilities  depiction 
-Gantt  chart  showing  time 
required  to  fix  the 
aircraft 

—Pie  chart  to  show  qua Is 
Figures  to  show  quantity 
-Printout  from  Material 
Control 

-Printout  from  Tool-Room 
-Screen  display  of  flight 
schedule 


2.  Operations  for  Intelligence, 
Design,  and  Choice. 

-Query  the  Data  Base 
-Expert  Advice 
-Prioritize  Aircraft 
-Print  summary  statistics 
on  each  aircraft 


3.  Automated  Memory  Aids 
-Scratchpad  for  Passdown 
-Spreadsheet  for  Scroll 

Box 

-Library  for  FCF  and  MESM 
-List  for  ADB  data 

4.  Aids  to  Direct,  Personal 
Control 

-On  line  Help 

—On  line  access  to  manuals 

-Default  values 

-Page  back  Capability 

-Menu  Displays 


Figure  4.5  ROMC  Application 
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running  the  system  as  easy  as  possible  thus  avoiding 
discouragement  of  users  who  are  not  comfortable  with  computer 
operations . 

Control  is  also  provided  by  ensuring  that  the  system 
is  in  compliance  with  applicable  Maintenance  Instructions 
(Mi's),  Standard  Operating  Procedures  (SOP's),  Technical 
Directives  (TD's),  Periodic  Maintenance  Inspection  Cards 
(PMIC's)  and  instructions  such  as  OPNAVINST  4790.  Actions 
recommended  by  the  system  must  conform  with  regulations  which 
bind  the  decision  maker.  This  requirement  identifies  a  need 
for  ongoing  system  support.  Squadrons  must  have  access  to, 
or  ensure  training  of,  someone  to  incorporate  publication 
updates  into  the  system.  The  squadron's  technical  publication 
librarian  could  be  trained  for  this  duty. 

Application  of  the  ROMC  approach  gives  some  definition 
to  what  the  system  should  look  like.  The  examples  cited  are 
a  sample  of  possible  features  and  an  illustration  of  how  these 
attributes  can  be  represented  using  ROMC.  A  more  detailed 
list  can  be  derived  from  close  observation  of  the  maintenance 
control  environment. 
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C.  SYSTEM  IMPLEMENTATION  AND  EVOLUTION 
1 .  Value  Analysis 

Value  analysis  has  been  identified  by  Keen  as  an 
alternative  to  cost-benefit  analysis  for  justifying  a  DSS/ES. 
To  use  value  analysis,  desired  benefits  are  identified  and  the 
value  to  the  user  of  attaining  these  benefits,  in  terms  of 
dollars,  is  assigned  to  determine  the  cost  threshold  for 
producing  the  first  prototype.  A  representative  sampling  of 
benefits  that  can  be  applied  to  a  maintenance  control  DSS/ES 
follow . 

Mitigation  of  the  shortage  of  experts  and  more 
effective  decision  making  are  the  primary  benefits  which 
should  result  from  implementation  of  a  DSS/ES  in  maintenance 
control . 

While  there  is  no  definite  and  easy  measure  of 
decision  quality  there  are  some  indicators.  Increased 
aircraft  readiness  rates  should  be  one  indication  of  better 
decisions.  A  decrease  in  the  ratio  of  maintenance  man  hours 
to  flight  hours  is  another.  Another  example  of  a  benefit  was 
shown  in  the  scenario,  aircraft  down  time  while  awaiting 
maintenance  (AWM)  could  have  been  reduced  by  matching 
maintenance  talent  to  aircraft  discrepancies. 
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A  further  possible  benefit  is  higher  morale  attained 
through  job  satisfaction.  Morale  may  be  diminished  by 
ineffective  decisions.  For  example,  poor  job  prioritization 
decisions  will  lead  to  a  lower  aircraft  readiness  posture  and 
may  result  in  longer  work  days  and  a  longer  work  week.  This 
scenario  will  most  definitely  affect  morale  if  continued  over 
a  sustained  period  of  time. 

Stress  reduction  due  to  faster  problem  response,  an 
increase  in  alternatives  examined,  employment  as  a  training 
aid  for  maintenance  control  personnel  and  a  better 
understanding  of  decision  factors  affecting  maintenance 
control  are  some  other  benefits  that  may  be  realized  through 
DSS/ES  implementation.  The  designer  and  user  must  decide 
which  of  these  benefits  are  to  be  prioritized  and  then  place 
a  value  on  attaining  them.  This  will  establish  the  maximum 
cost  for  prototype  development. 

2 .  Prototyping  and  Adaptive  Design 

The  initial  prototype  should  be  simple  to  operate  and 
valuable  to  the  user  in  performing  a  routine  decision  task. 
The  objective  is  early,  effective  implementation  which 
establishes  value  thus  gaining  user  acceptance.  Prior  to 
prototype  construction,  close  archipelagean  scrutiny,  as 
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is  advised  to  avoid  costly 


described  in  Chapter  II, 
development  of  an  infeasible  project. 

An  aircraft  assignment  DSS  is  suggested  as  the  initial 
prototype.  The  prototype  software  should  be  compatible  with 
the  Z-248  computer  which  is  currently  available  for 
procurement.  An  "off  the  shelf"  software  package  capable  of 
linear  programming  could  be  utilized. 

The  authors  envision  a  prototype  which  will  optimize 
aircraft  assignments  based  on  mission  requirements,  aiiraft 
capability,  and  scheduled  maintenance  limitations.  The  MCC 
can  experiment  with  "what  if"  questions  to  determine  the 
optimum  utilization  of  his  assets  based  on  mission 
requirements  and  scheduled  maintenance. 

Benefits  for  value  analysis-cost  threshold  purposes 
include  better  decision  making,  increased  readiness  rates,  and 
an  increase  in  the  number  of  alternatives  examined.  After 
testing,  the  prototype  will  be  evaluated  on  how  well  it 
fulfilled  these  expectations. 

During  the  testing  process  the  MCC  will  probably  make 
suggestions  on  other  desirable  functions  for  the  system  in 
addition  to  those  already  planned.  These  ideas  should  be 
subjected  to  value  analysis  and  the  archipelagean  method.  If 
deemed  feasible,  the  project  can  proceed  to  the  next  version 
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and  the  process  is  repeated  again,  starting  the  adaptive 
design  process. 

This  modular  approach  using  value  analysis  and 
adaptive  design  can  continue  until  no  more  capabilities  are 
identified.  Value  analysis  will  guard  against  cost  over  runs 
and  project  infeasibility  with  the  end  result  being  a  powerful 
DSS/ES  for  use  in  maintenance  control. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


Naval  aviation  maintenance  managers  operate  in  a  complex 
decision  making  environment  where  maintenance  control  is  the 
focal  point.  The  opportunity  for  improved  performance  by 
maintenance  control  decision  makers  is  the  primary 
justification  for  the  development  and  implementation  of  a 
maintenance  control  DSS/ES. 

A.  CONCLUSIONS 

This  thesis  has  examined  design,  implementation,  evaluation 
and  evolution  issues  involved  with  the  development  of  a 
maintenance  control  DSS/ES.  A  set  of  DSS/ES  design  criteria 
has  been  developed  which  provide  the  design  engineer  with 
information  about  the  decision  environment  and  proposed 
system.  These  criteria  are  used  in  the  ROMC  framework  to 
provide  a  blueprint  of  system  characteristics.  Prototyping 
and  an  adaptive  design  methodology  are  recommended  as  the  most 
suitable  alternatives  for  system  design  and  implementation. 
Because  of  the  difficulty  of  conducting  a  cost-benefit 
analysis  for  DSS/ES,  value  analysis  is  the  preferred 
justification  technique.  The  final  system  characteristics  may 


91 


defy  advance  definition,  therefore  value  analysis  and  adaptive 
design  are  recommended  as  the  procedures  to  be  used  as  the 
system  evolves.  The  following  paragraphs  provide  more  detail 
on  each  of  these  conclusions. 

1 .  Design  Criteria 

A  design  engineer  must  have  certain  information  about 
a  proposed  system  prior  to  starting  design.  This  information 
is  referred  to  as  the  design  criteria.  In  Chapter  IV  a 
detailed  discussion  of  the  design  criteria,  appropriate  for 
a  maintenance  control  DSS/ES,  was  completed.  By  using  the 
following  set  of  design  criteria,  the  design  engineer  will 
ensure  the  availability  of  the  information  required  to 
confidently  proceed  to  the  next  phase  in  the  development  of 
a  maintenance  control  DSS/ES.  Applicable  maintenance  control 
issues  and  situations  are  included  as  examples. 

1 .  Identify  the  need  for  a  DSS/ES. 

Not  all  problem  environments  are  well  suited  for  a 
DSS/ES  solution.  Emphasis  should  be  on  those 
environments  which  contain  ill-structured  problems. 
Maintenance  control  is  a  complex  decision  making 
environment  due  to  the  existence  of  ill-structured 
problems,  e.g.,  aircraft  scheduling,  scheduled  and 
unscheduled  maintenance  and  work  load  prioritization. 

2 .  Identify  the  decision  making  factors . 

Decision  making  factors  are  those  which  prompt  and 
direct  the  course  of  decisions  made  to  meet  end  goals. 
Such  factors  include  identification  of  inputs/outputs, 
available  resources,  cognitive  style  and  decision 
making  pressures  exerted  through  organizational 
structure . 


92 


The  inputs  to  maintenance  control  are  aircraft 
discrepancies  and  the  flight  schedule.  These  inputs 
prompt  maintenance  decisions  which  result  in  repaired 
aircraft  and  aircraft  assignments  to  the  flight 
schedule,  the  outputs. 

Resources  available  to  the  maintenance  manager  are 
categorized  into  five  areas,  facilities,  people, 
logistics,  tools  and  test  equipment,  and  time. 

Individual  cognitive  style  is  not  an  appropriate 
concern  in  the  maintenance  control  environment  due  to 
the  large  number  of  users.  Therefore,  a  user  friendly 
system  which  incorporates  flexibility  by  providing  a 
variety  of  user  options,  e.g.,  menus,  default  options, 
color,  etc.,  is  important. 

There  is  an  organizational  decision  making  pressure 
exerted  in  maintenance  control.  This  pressure  exists 
in  the  form  of  written  SOP  meant  to  direct  the 
decision  maker  with  most  programs. 

3 .  Identify  the  present  "dss". 

Successful  design  of  a  computerized  DSS  must 
incorporate  the  noncomputerized  decision  tools  of  the 
user,  a  dss.  This  will  promote  system  acceptance  by 
providing  the  user  with  information  in  a  familiar 
format.  Typical  maintenance  control  decision  making 
tools  include  VlDs  Boards,  SOP,  ADBs ,  etc. 

4 .  Identify  the  ill-structured  problems. 

Since  ill-structured  problems  are  of  concern  to  DSS/ES 
designers,  they  need  to  be  identified  and  targeted  for 
solution.  In  maintenance  control  such  problems 
include  JCN  prioritization  and  aircraft  scheduling. 

5 .  Identify  problem  related  data. 

Once  problems  have  been  identified,  the  required  data 
necessary  for  their  solution  can  be  captured  and 
stored  for  retrieval  and  manipulation.  For  example, 
most  of  the  scheduled  maintenance  requirements  are 
dictated  by  aircraft  hours  flown.  Therefore,  flight 
hours  consumed  per  aircraft  will  have  to  be  captured 
and  stored. 
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6. 


After  the  ill-structured  problems  and  relevant  data 
have  been  targeted  for  DSS/ES  solution,  the  design 
engineer  must  decide  what  type  of  model  design  is 
necessary  to  form  satisfactory  solutions.  Most  models 
will  incorporate  an  algorithmic  solution  structure. 
For  scheduled  maintenance,  the  manipulation  of 
aircraft  flight  hours  will  involve  simple  arithmetic 
summing  operations. 

7 .  Identify  the  required  heuristic  rule  bases. 

Some  problem  solutions  can  only  be  derived  through 
heuristic  rule  base  inferencing  vice  algorithmic 
methods.  Such  rule  bases  must  be  identified  and 
captured  through  knowledge  acquisition.  Job  control 
number  prioritization  will  require  such  an  effort. 
What  discrepancies  should  be  worked  on,  for  what 
aircraft  and  in  what  order  is  a  daily  puzzle  that  does 
not  lend  itself  well  to  mathematical  algorithms. 

2 .  System  Design  end  Implementation 

An  adaptive/prototype  design  approach  is  the  preferred 
method  for  design  and  implementation  of  the  maintenance 
control  DSS/ES.  Representations,  Operations,  Memory  aids  and 
Control  mechanisms  provide  a  framework  for  system 
construction.  The  ROMC  method  helps  convert  the  user's  dss 
into  a  computerized  DSS.  This  process  defines  the  functional 
requirements  and  capabilities  of  a  DSS  and  facilitates  design 
of  the  user  interface  while  taking  into  account  appropriate 
cognitive  style. 

Traditional  "life  cycle"  design  involving  lengthy  and 
intensive  analysis  of  user  requirements,  often  falls  short 
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when  applied  to  a  DSS/ES.  Prototyping  is  recommended  as  the 
appropriate  design  methodology  when  building  a  DSS/ES.  The 
prototype  should  perform  a  simple  yet  needed  user  function  and 
should  accommodate  an  adaptive  design  process.  A  prototype 
with  a  specific  function  permits  quick  implementation  and 
encourages  early  user  feedback.  Early  user  involvement  in  the 
process  helps  to  identify  requirements,  to  shape  the  system 
and  to  reduce  user  resistance. 

3 .  Evaluation 

Because  of  the  numerous  intangible  benefits  associated 
with  a  DSS/ES,  traditional  cost-benefit  analysis  will  not 
provide  justification  for  a  system.  Value  analysis  provides 
ongoing  justification  for  each  module  of  the  system  by 
assigning  value  to  desired  capabilities.  Testing  evaluates 
whether  those  capabilities  have  been  provided  and  identifies 
new  system  enhancements.  Each  new  module  should  be  subjected 
to  thorough  scrutiny  to  determine  its  feasibility,  i.e.,  is 
it  too  difficult  or  costly. 

4 .  Evolution 

Adaptive  design  methods  encourage  DSS/ES  evolution. 
An  adaptive  process  allows  for  orderly  system  expansion  by 
adding  functional  modules.  This  allows  for  earlier  deployment 
of  an  initial  capability  with  planned  expansion  as 
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requirements  and  funding  permit.  This  approach  is  recommended 
for  the  maintenance  control  DSS/ES  and  will  provide  a  means 
for  the  system  to  grow  into  a  powerful,  useful  tool. 

B .  RECOMMENDATIONS 

The  following  recommendations  are  made  concerning  the 
development  and  implementation  of  a  DSS/ES  for  maintenance 
control.  Suggestions  concerning  further  research  are  also 
provided . 

1.  Maintenance  Control  DSS/ES 

Maintenance  control  decision  makers  will  benefit  from 
a  computerized  decision  support  system  that  lends  structure 
to  ill-structured  problems.  Using  the  developed  design 
criteria  as  a  guide,  engineers  can  verify  the  need,  and 
identify  the  problems,  data,  models,  and  heuristic  rule  bases 
required  for  an  effective  system. 

An  initial  prototype  which  aids  the  decision  process 
in  a  select  area  should  be  implemented  early  in  the 
development  process  in  order  to  profit  from  user  insight. 
An  initial  system  which  aids  the  MCC  with  flight  schedule 
assignments  is  recommended.  This  system  will  match  an 
aircraft's  present  capability,  based  on  discrepancies  logged 
against  the  aircraft,  with  the  requirements  of  the  mission, 


96 


as  defined  in  the  MESM.  Additional  information  informing  the 
decision  maker  as  to  the  number  of  hours  remaining  before  any 
scheduled  maintenance  commitment  and  other  pertinent 
information  would  be  provided. 

This  system  will  require  a  database  which  contains  the 
MESM  mission  requirements  for  aircraft  systems  and  scheduled 
maintenance  commitments  per  aircraft.  Aircraft  flight  hours 
flown,  data,  will  have  to  be  collected  and  entered  in  the 
database.  A  model  which  matches  mission  requirements  with 
aircraft  capabilities,  and  compares  hours  flown  with  hours 
remaining  will  be  required. 

After  successful  implementation  of  the  "Aircraft 
Assignment"  model,  solutions  to  other  problems  can  be  planned 
and  implemented  in  an  adaptive  fashion  as  separate 
modules.  It  is  critical  that  the  initial  system  capture  user 
interest  and  confidence  to  ensure  system  success.  Each  module 
should  undergo  a  thorough  feasibility  study  before  development 
and  construction  costs  are  incurred. 

2.  Relevant  Additional  Research 

The  development  and  implementation  of  a  DSS/ES  for 
maintenance  control  work  centers  throughout  the  Navy  will  be 
a  large  undertaking.  Costs  must  be  justified,  problem  areas 
targeted  and  a  prototype  must  be  developed  and  tested.  The 
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following  are  the  authors'  recommendations  for  additional 
research  to  address  these  issues. 


1 .  Value  analysis  research. 

Research  must  be  done  to  specifically  identify  the 
benefits  to  be  gained  through  the  employment  of  a 
DSS/ES  for  value  analysis  use.  Because  squadrons  have 
differing  missions  and  operating  environments  this 
study  should  cover  a  broad  spectrum  of  Navy  and  Marine 
Corps  activities. 

2  .  Study  of  the  environment. 

An  in-depth  examination  of  the  maintenance  control 
environment  should  be  conducted  to  specifically 
identify  problems  and  critical  success  factors 
associated  with  maintenance  control.  Again,  a  broad 
sampling  of  Navy  and  Marine  Corps  squadrons  should  be 
included . 

3  .  Development  of  a  prototype . 

A  prototype  should  be  constructed  which  demonstrates 
the  feasibility  and  use  of  such  a  system  in  the 
maintenance  control  environment.  It  is  feasible  and 
cost  effective  to  have  the  initial  prototype  developed 
and  tested  as  thesis  work  at  the  Naval  Postgraduate 
School . 


Our  analysis  suggests  that  the  development  and 
implementation  of  a  computerized  decision  support  system  will 
improve  the  decision  performance  of  maintenance  managers. 
This  performance  will  result  in  a  higher  state  of  material 
readiness  throughout  naval  aviation.  The  design  criteria  and 
implementation  suggestions  provided  in  this  thesis  are 
necessary  steps  for  a  successful  development. 
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APPENDIX 


3-M 

ADB 

ADI 

AE 

AIMD 

ALSE 

AMS  2 

AZ  ' 

CEO 

CNO 

CSF 

DBMS 

DDM 

DSS 

dss 

DPF 

ES 

EDP 

FCF 


GLOSSARY  OP  ACRONYMS 

Maintenance  Material  and  Management 
Aircraft  Discrepancy  Book 

Aviation  Power  Plants  Mechanic  First  Class 
Aviation  Electrican 

Aircraft  Intermediate  Maintenance  Department 

Aviation  Life  Support  Equipment 

Aviation  Structural  Mechanic  Second  Class 

Aviation  Administration 

Chief  Executive  Officer 

Chief  of  Naval  Operations 

Critical  Success  Factors 

Database  Management  System 

Dialog-Database-Model 

Decision  Support  System  (computerized) 
decision  support  system  (noncomputerized) 
Development  Priority  Factor 
Expert  System 

Electronic  Data  Processing 
Functional  Check  Flight 
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FMC 

Fully  Mission  Capable 

JCN 

Job  Control  Number 

MCC 

Maintenance  Contorl  Chief 

MESM 

Mission  Essential  Support  Matrix 

MI 

Maintenance  Instruction 

MIS 

Maintenance  Information  System 

MMCO 

Maintenance  Material  Control  Officer 

MO 

Maintenance  Officer 

NALCOMIS 

Naval  Aviation  Logistics  Command  Management 
Information  System 

NAMP 

Naval  Aviation  Maintenance  Program 

NMC 

Not  Mission  Capable 

OPNAVINST 

Office  of  the  Chief  of  Naval  Operations 

Instruction 

PDL 

Passdown  Log 

PERT 

Program  Evaluation  and  Review  Technique 

PMCM 

Partial  Mission  Capable  Maintenance 

PMCS 

Partial  Mission  Capable  Supply 

PMIC 

Periodic  Maintenance  Information  Cards 

QA 

Quality  Assurance 

R&D 

Research  and  Development 

ROI 

Return  On  Investment 

ROMC 

Representations,  Operations,  Memory  Aids 
Mechanisms 

and  Control 

SDLM 

Standard  Depot  Level  Maintenance 
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SE 

SOP 

TD 

VID 


Support  Equipment 
Standard  Operating  Procedures 
Technical  Directive 
Visual  Information  Display 
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